By Greg Nowak. Updated October 7, 2026.
If you own several WordPress sites, or maintain them for clients, an emergency update announcement leaves one practical question: did every installation actually receive it?
WordPress enabled forced updates for affected versions after its July 17 security release. But the announcement explicitly limited automatic delivery to sites that support background updates. An update email or hosting dashboard is useful evidence; you still need to confirm the installed version on each site. For a business owner, the useful outcome is a checked list of sites, unresolved problems and who owns the next action.
What the emergency update fixed
The WordPress 7.0.2 announcement described one critical and one high-severity issue: SQL injection and a REST API batch-route weakness that could combine with SQL injection to allow remote code execution.
The July fixes were 7.0.2 for the 7.0 branch, 6.9.5 for 6.9, and 6.8.6 for 6.8. The 6.8 branch was affected by the SQL-injection issue only; versions before 6.8 were unaffected by these particular vulnerabilities. That does not establish their overall security.
CISA added both CVE-2026-60137 and CVE-2026-63030 to its Known Exploited Vulnerabilities Catalog on July 21. An installation that missed the patch therefore deserves an exposure review as well as an update.
The July fix is no longer the update target
As of October 7, the official release archive lists WordPress 7.1.3, released October 6, as the latest release. It identifies only the most recent release in the 7.1 series as safe to use and actively maintained.
Plan for the latest stable release. If a critical integration temporarily prevents that move, apply the newest available patch for the installed branch and document the remaining limitation. Give the full upgrade an owner and deadline; an older branch receiving backports is not a promise of continuing support.
Use a status that tells people what happens next
| Finding | Next action | Evidence to retain |
|---|---|---|
| Version not checked | Verify the installation directly | Hostname, path, version and check time |
| Missing the July fix | Patch promptly and review exposure | Previous version, logs and update history |
| July fix present, later updates missing | Update to the agreed current target | Target version and upgrade owner |
| Unexpected files or accounts | Escalate for investigation | Preserved files, logs and account details |
| Updated and tested | Close the maintenance task | Version, integrity results and journey checks |
How to verify every WordPress installation
1. Reconcile the site list
Check hosting accounts, domain records, deployment repositories and maintenance agreements against your existing register. Include staging copies, campaign sites, regional sites and old migrations that remain reachable. Decide whether each installation should be maintained, restricted or retired.
Record the hostname, installation path, environment, host, business owner, technical owner, observed version and verification time. For agencies, make responsibility explicit where the client, agency and hosting provider share the work.
2. Read the installed version
With WP-CLI available, run these commands from the correct WordPress installation directory:
wp core version
wp core check-updateSave the output against that installation. If you lack shell access, check Dashboard → Updates and ask the host or maintainer to confirm the deployed version. Mark inaccessible sites as unresolved rather than assuming they updated with the rest.
3. Apply the update through the right process
Confirm you have a usable backup of the database and files, and a recovery route. Test critical integrations on staging where feasible. If suspicious changes are already visible, preserve evidence before overwriting files.
On installations maintained directly with WP-CLI, the core update command updates to the latest version by default:
wp core update
wp core versionFor sites deployed from a repository or managed platform, use that deployment process so the next deployment retains the patch. If an automatic update failed, have the maintainer check Site Health, update configuration, file ownership and permissions, and the recorded error. Resolve the cause alongside the manual patch.
4. Check core file integrity
Compare installed core files with WordPress.org’s checksums:
wp core verify-checksums --include-root --version=$(wp core version)The checksum command runs before WordPress loads. Add the correct --locale for a non-default language package. For collecting results across installations, --format=json provides structured messages; retain the command’s success or failure status too.
Investigate mismatches. The --include-root option also warns about non-WordPress items in the root directory, which may be legitimate. A clean result verifies core files; it does not clear plugins, themes, uploads, configuration, administrator accounts or the database.
5. Test what the business needs
Check more than the homepage. Test a form submission through to delivery, a purchase through to payment confirmation, or a publishing action through to the public page. Include relevant login, CRM connections and scheduled tasks. Record the result and tester, and assign any failures before closing the work.
When does a missed update need investigation?
A vulnerable version does not prove compromise, and installing a patch does not remove an existing compromise. Establish when the site was last known to be patched and whether it was reachable during the gap.
Unfamiliar administrator accounts, unexplained file changes, suspicious requests or altered scheduled tasks justify escalation. Preserve relevant logs and files before deleting or rebuilding. Where evidence is missing, record that uncertainty; an absence of retained logs cannot establish that nothing happened.
Make the next emergency easier to handle
Keep automatic delivery and independent verification in your maintenance routine. Agree who monitors releases, who checks installations, who tests business journeys and who handles exceptions.
Greg can help bring the inventory, hosting and agency responsibilities into one workable process. If you need a clear view of which sites are patched and what remains unresolved, discuss a WordPress estate review with Greg.
Related on GrN.dk
- WordPress Security Updates Need an Ops Runbook
- AI automations need a spend dashboard before the first runaway bill
- Can’t Publish in WordPress? Fix the Invalid JSON Response Without Guesswork
Need help with this kind of work?
Discuss your WordPress sites with Greg Get in touch with Greg.
