By Greg Nowak. Updated September 5, 2026.
WordPress pushed an emergency update on July 17, 2026, addressing one critical and one high-severity security issue. Forced updates were enabled for affected installations, but only sites capable of running automatic background updates could receive them automatically.
That distinction matters. “WordPress forced the update” describes the delivery mechanism; it does not prove that every production site, staging copy, campaign site or forgotten installation actually reached a safe version.
There is now another reason to check. CVE-2026-60137, the SQL-injection vulnerability involved in the release, was added to CISA’s Known Exploited Vulnerabilities Catalog on July 21. A site found unpatched should therefore be treated as a possible exposure requiring review—not merely as an overdue maintenance task.
What the July emergency release fixed
WordPress 7.0.2 fixed insufficient sanitisation of the author__not_in parameter in WP_Query. The weakness, tracked as CVE-2026-60137, could enable SQL injection when a plugin or theme passed untrusted input into that parameter.
WordPress 6.9 and 7.0 were also affected by a REST API batch-route confusion issue. According to the WordPress security advisory, combining the two weaknesses could lead to remote code execution. WordPress 6.8 was affected by the SQL-injection issue but not that critical chain.
| Version found during review | July exposure | July minimum fix | Action now |
|---|---|---|---|
| Earlier than 6.8 | Not affected by these two July issues | Not applicable | Do not mark it safe overall; assess its unsupported or legacy status separately |
| 6.8.x before 6.8.6 | SQL injection | 6.8.6 | Update beyond the July minimum and review the exposure window |
| 6.9.0–6.9.4 | Both vulnerabilities | 6.9.5 | Update beyond the July minimum and begin an exposure review |
| 7.0.0–7.0.1 | Both vulnerabilities | 7.0.2 | Update beyond the July minimum and begin an exposure review |
| 7.1 beta before beta 2 | Both vulnerabilities | 7.1 beta 2 | Replace the beta with the stable current release |
Do not stop at 7.0.2
Reaching 7.0.2 proved that the July fixes had landed at that moment. It is no longer a suitable definition of “fully patched.” WordPress published further security releases in August, followed by stable WordPress 7.1 on August 19. As of September 5, the official release archive identifies 7.1 as the current, actively maintained release.
Where compatibility permits, move to the latest stable release. If a business-critical integration temporarily keeps a site on an older branch, install the newest available backport for that branch and give the upgrade a named owner and deadline. Do not leave “we run an old branch” as an indefinite operating policy.
A verification workflow you can defend
1. Find every installation
Start with the known production and staging estate, then reconcile it against hosting accounts, domain records, deployment repositories and maintenance agreements. Include regional sites, campaign domains, old migrations and development copies that remain reachable from the internet.
Your working register should capture the hostname, environment, business owner, technical owner, hosting location, observed version, target version, verification time and follow-up status. Keep “automatic updates enabled” separate from “patched version observed.”
2. Observe the installed version
With WP-CLI available, start with:
wp core version
Then check what WordPress currently offers:
wp core check-update
Take the appropriate backup or platform snapshot, apply the approved update and read the version again. wp core update updates to the latest version by default; use an explicit version only when your documented branch policy requires it.
3. Verify the core files
After updating, compare the installed core files with WordPress.org’s checksums:
wp core verify-checksums --include-root --version=$(wp core version)
The command runs before WordPress loads. --include-root also warns about unexpected items in the installation root, while --format=json can make fleet results easier to collect. Pass the correct --locale if the installation does not use the default locale.
A checksum failure needs investigation, but a clean result is not a clean bill of health. Core verification does not clear administrator accounts, logs, configuration, plugins, themes or files in wp-content.
4. Test the business journeys
Confirm that the site still performs the job the organisation pays for. Depending on the installation, that may mean checking authentication, forms, publishing, search, checkout, payment callbacks, CRM integrations and scheduled tasks. Record the checks rather than relying on “the homepage loaded.”
When a late update becomes an incident question
A site discovered in an affected range was exposed; that alone does not prove compromise. Escalate the review when you find unfamiliar administrator accounts, unexplained file changes, checksum failures, suspicious requests, altered scheduled tasks or uncertainty about how long the site remained reachable and vulnerable.
Preserve relevant logs and evidence before deleting files or rebuilding the installation. The depth of the review should reflect the site’s exposure, the data and credentials it can access, and the anomalies actually found.
Make the next forced update less dramatic
Automatic updates are valuable, but they are not an inventory or an audit trail. A reliable WordPress operation needs both automatic delivery and independent confirmation across the whole estate.
Greg can help agencies and in-house teams assemble that inventory, verify versions and file integrity, investigate failed background updates, coordinate safe upgrades and test the journeys that matter. If your answer to “did every site take it?” is still uncertain, get in touch for a practical WordPress fleet review.
Related on GrN.dk
- WordPress Security Updates Need an Ops Runbook
- Can’t Publish in WordPress? Fix the Invalid JSON Response Without Guesswork
- Drupal Automatic Updates After the Legacy API Shutdown: A Practical Fix Plan
Need help with this kind of work?
Discuss your WordPress fleet with Greg Get in touch with Greg.
