A business website can look completely normal while its software is badly behind. The homepage loads, the contact form appears, and nobody receives an obvious warning. That is why this week's WordPress security release deserves attention from owners, not only developers.
WordPress released version 7.0.2 on July 17. The project says the release fixes one critical and one high severity security issue and recommends that affected sites update immediately. Four days later, the United States Cybersecurity and Infrastructure Security Agency added both flaws to its Known Exploited Vulnerabilities catalog.
That catalog is the important part. It means there is evidence that attackers are using the flaws outside a lab. It does not mean every WordPress website has been compromised, but it does move this update out of the "deal with it later" pile.
If your business uses WordPress, the useful question is not whether automatic updates are turned on. The useful question is which version is running right now, who verified it, and whether the site still works after the patch.
What the update fixes
The two issues are tracked as CVE-2026-60137 and CVE-2026-63030. The official WordPress security release describes one SQL injection issue and one REST API batch-route confusion issue. CISA's Known Exploited Vulnerabilities entries say the flaws can be chained to allow an unauthenticated attacker to run code on an affected default installation.
Running code remotely is a serious outcome. It can give an attacker a path to alter pages, add administrator access, steal information available to the site, redirect visitors, or use the server for another purpose. The exact impact depends on the hosting environment, site configuration, and what other systems the website can reach.
WordPress 6.9 is affected by both flaws. The fixed backport is version 6.9.5. WordPress 6.8 is affected by the first flaw and has a fix in version 6.8.6. Versions before 6.8 are not affected by these two specific issues, according to WordPress, although running an old unsupported release is not a security strategy.
Why the CISA listing changes the priority
Security teams track thousands of disclosed vulnerabilities. Most never become a practical priority for a small business because the affected software is not present, the flaw is difficult to use, or there is no evidence of active attacks.
CISA's Known Exploited Vulnerabilities catalog is narrower. CISA added both WordPress flaws on July 21 after confirming active exploitation. The agency set remediation dates for United States federal systems, but private businesses can use the same signal to decide which patches should jump the queue.
A long vulnerability list creates noise. Evidence of active exploitation gives a business a reason to patch one item before the rest.The five checks an owner can ask for today
You do not need administrator access or a security certification to ask useful questions. Whether an employee, freelancer, agency, or hosting company manages the site, request these five checks:
- Confirm the platform and installed version. Do not assume the site uses WordPress because it has a familiar editor, and do not assume an update ran because automatic updates are enabled.
- Confirm a recent restorable backup. The backup should include both website files and the database. Someone should know where it is stored and how to restore it.
- Install the fixed core release. An affected WordPress 7.0 site should be on 7.0.2. Supported 6.9 and 6.8 sites should use the fixed backports WordPress published for those branches.
- Review plugins, themes, and administrator accounts. A secure core does not repair an outdated plugin or remove an account that should no longer have access.
- Test the parts that make the website useful. Submit the contact form, complete a booking or payment test where applicable, verify email delivery, and sign in through both customer and administrator paths.
Automatic updates still need verification
WordPress enabled forced updates for affected versions because of the severity. That should protect many sites quickly. It can also create false confidence if nobody checks the result.
Background updates can be blocked by hosting rules, file permissions, disabled update settings, custom deployment processes, or a failed write. The update can also finish while a plugin or custom theme exposes a separate problem. The correct routine is simple: back up, update, verify the version, test the business functions, and record the result.
That record does not need to be elaborate. A maintenance entry with the date, old version, new version, backup reference, test results, and the person who performed the work is enough. Six months from now, it answers a question that memory will not.
Website security is an ownership question
Many small business websites sit in an awkward gap. The owner assumes the hosting company handles updates. The hosting company provides the server but does not maintain the application. The original developer completed the project years ago and is no longer involved. Everyone thinks someone else owns patching.
Fixing that gap matters beyond this WordPress release. Write down who owns core updates, plugin updates, backups, monitoring, and recovery. Define how quickly critical actively exploited flaws should be handled. Keep the website credentials in a business-controlled account rather than one person's private login.
If your Windsor or Essex County business is unsure what runs its website, which version is installed, or who is responsible for maintaining it, email NeuroDesk at hello@neurodesk.co. We can inspect the current setup, document who owns each part, and turn emergency patching into a routine process.