WordPress Forced an Emergency Update. Did Every Site Take It?
By Greg Nowak. Last updated 2026-07-18.
WordPress 7.0.2 was published on July 17, 2026 to fix one critical and one high-severity security issue. WordPress recommended installing it immediately and, given the severity, switched on forced updates through its automatic-update system for affected sites.
That should protect a large part of the WordPress estate quickly. It does not prove that every site you are responsible for has been patched.
The release announcement says automatic processing begins on sites that support background updates. That condition matters. Agencies, site owners and technical teams still need evidence from each installation, especially when they manage a mixture of production sites, staging environments and old projects with uncertain ownership.
What the emergency release fixes
The critical issue is a chain involving two vulnerabilities. CVE-2026-60137 concerns insufficient sanitisation of the author__not_in parameter in WP_Query. SQL injection can become possible when a plugin or theme passes untrusted input to that parameter.
CVE-2026-63030 is a route-confusion issue in the REST API batch endpoint. Combined with the SQL-injection weakness, it can let an attacker move from SQL injection to remote code execution. The WordPress security advisory classifies the chain as critical and recommends updating immediately.
The affected version matters. WordPress 6.8 is vulnerable to the SQL-injection issue, but not to the critical route-confusion chain. WordPress 6.9 and 7.0 are affected by both. A spreadsheet entry that says only “old WordPress” is therefore not enough to choose the fix or judge the exposure.
| Installed branch | Reported exposure | Version to confirm | Required action |
|---|---|---|---|
| Earlier than 6.8 | Not affected by these two issues | Record the exact version | Manage its wider lifecycle separately; do not mark it affected by this release |
| 6.8.x before 6.8.6 | CVE-2026-60137 | 6.8.6 | Patch and verify |
| 6.9.0–6.9.4 | Both vulnerabilities | 6.9.5 | Patch immediately, verify and assess exposure |
| 7.0.0–7.0.1 | Both vulnerabilities | 7.0.2 | Patch immediately, verify and assess exposure |
| 7.1 beta before beta2 | Both vulnerabilities | 7.1 beta2 | Update the test installation and confirm it is not serving production traffic |
Forced does not mean verified
The WordPress release announcement confirms that forced updates were enabled for affected versions. It also makes clear that automatic processing applies to sites capable of background updates.
The operational question is narrower and more useful: which installations actually reached the correct patched version?
Checking the main corporate site will not answer it. A WordPress estate may include campaign sites, regional installations, staging and development copies, migration remnants or sites that have fallen outside the normal dashboard workflow. Some may sit in a hosting account nobody checks regularly. The scope is every reachable installation for which the organisation remains responsible.
A workable site register should capture the hostname, environment, owner, hosting location, installed WordPress version, expected patched version, update result, verification time and person handling any follow-up. Keep “auto-updates enabled” and “patched version observed” as separate fields. They describe different things.
A verification workflow you can stand behind
1. Find the whole estate
Start with the known production and staging sites. Reconcile that list against existing hosting accounts, domain records, deployment documentation and maintenance agreements. If ownership is unclear, record that explicitly. Keep the site in the queue until someone accepts responsibility, retires it or confirms that it is outside scope.
2. Read the installed version
Record the core version observed in each environment and compare it with the fixed release for that branch. In this incident, 6.8.6, 6.9.5 and 7.0.2 are separate security backports, not interchangeable labels.
The WordPress advisory identifies versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 as affected by the critical chain. The NVD record for CVE-2026-60137 also covers vulnerable 6.8.x releases before 6.8.6.
3. Patch anything still exposed
If an affected version is still installed, do not wait for another automatic-update cycle. Apply the appropriate supported update, confirm that the command or dashboard action finishes, then read the installed version again. That observed post-update state is the evidence worth keeping.
4. Check WordPress core files
Once the version is correct, run wp core verify-checksums. WP-CLI downloads the official checksums for the current WordPress version and compares them with the installed files. The command runs before WordPress loads, so verification is less dependent on the application itself.
The locale and version need to match the installation. WP-CLI provides --locale and --version for this. --include-root can flag non-WordPress items in the root directory, while --format=json makes results easier to collect across multiple sites.
A failed or unexpected checksum is a finding to investigate. A clean result is useful, but limited: it confirms that the checked core files match the official checksums for that version. It does not clear accounts, logs, plugins, themes, configuration or business functionality.
5. Test what the site is there to do
Finish with a short functional check. The exact list depends on the site, but it may include page delivery, authentication, forms, search, checkout, publishing, integrations and scheduled tasks. Record what was tested and whether the update created any need for corrective work or rollback.
When patching should lead to an incident review
A site discovered on 6.9.0–6.9.4 or 7.0.0–7.0.1 was in the affected range for the critical chain. That does not show that the site was compromised. It does justify more scrutiny than applying the patch and quietly closing the ticket.
Reasons to escalate include an unexplained checksum failure, unfamiliar administrator accounts, unexpected file changes, suspicious requests in available logs or uncertainty about how long the installation remained exposed. Preserve relevant evidence before replacing or deleting anything. The site’s purpose, the access it holds and the findings should determine how far the review goes.
No alert is not the same as evidence of a clean system. Equally, finding a late update is not grounds for declaring a breach without supporting evidence.
Make the next urgent update easier
Automatic updates are valuable delivery infrastructure. Fleet verification is a separate operational job, and a reliable WordPress setup needs both.
Greg can help assemble the site inventory, check versions and core files with WP-CLI, find disabled or failed background updates, apply the right branch patches and test the journeys that matter. If exposure or anomalies warrant a closer look, the work can extend to logs, administrator accounts and modified files.
The immediate task is to show that every in-scope installation has the correct fix. The useful long-term outcome is a maintained register and a repeatable process that produces the same answer quickly when the next urgent security release lands.
Related on GrN.dk
- Background AI Tasks Need Queues, Not Just Longer API Calls
- Support bots need a deletion test before they learn the old help center
- The latest WordPress supply-chain attack was a CDN problem too
Need help with this kind of work?
Verify your WordPress fleet Get in touch with Greg.