wp2shell: the 'forced' WordPress patch that may have silently skipped your site

By now you've probably seen the headline: a critical WordPress vulnerability nicknamed wp2shell, unauthenticated, no plugins required, letting an attacker run code on a stock install. WordPress.org responded fast — a forced security release, pushed automatically to every supported site. Crisis handled.

Except "pushed to every site" and "installed on every site" aren't the same claim, and WordPress.org has been careful not to say the second one.

What's actually going on

wp2shell is two bugs chained together:

• CVE-2026-60137 — a SQL injection in WordPress core, present since version 6.8.
• CVE-2026-63030 — a logic flaw in the REST API's batch endpoint (/wp-json/batch/v1), introduced in 6.9. When a malformed sub-request path fails validation, the error lands in the wrong internal array, desynchronizing the batch processor so a later request gets dispatched to the wrong handler entirely.

Chained, an anonymous attacker gets remote code execution. No login, no plugin, no theme required — a completely default install of 6.9.0–6.9.4 or 7.0.0–7.0.1 is exploitable as-is (6.8.x carries the SQL injection alone, patched separately). Security researchers had proof-of-concept exploits public within days, and both CVEs landed on CISA's Known Exploited Vulnerabilities catalog on July 21 — confirmation this isn't theoretical, it's actively being used.

WordPress patched it in 6.8.6, 6.9.5, and 7.0.2, and — because of the severity — enabled forced updates through the auto-update system, overriding sites that would normally wait for a maintenance window.

1. 01 Malformed request A crafted /wp-json/batch/v1 request bundles a sub-request with a broken path.
2. 02 Arrays desync wp_parse_url() fails silently. The error reaches the validation array, not the execution array.
3. 03 Wrong handler runs A later sub-request — including one carrying a SQL-injection payload via author_exclude — dispatches under a handler it was never authorized to reach.
4. 04 Unauthenticated RCE No login, no plugin. An anonymous visitor injects SQL and executes code on the server.

The part that isn't getting said clearly enough

Forced auto-updates are a WordPress feature, not a magic override of physical reality. For the update to actually write new files, the process running WordPress needs write access to WordPress's own core files. If it doesn't, the update fails — quietly, with nothing shown to the site owner unless someone happens to be watching a debug log.

And a lot of sites don't have that write access on purpose. Locking down file ownership so a compromised web process can't modify core PHP files has been standard advice in WordPress hardening guides for the better part of a decade. Plenty of security-conscious hosts and agencies set exactly this up — often as part of the same "harden this site" engagement that was supposed to make it safer.

So the uncomfortable version of this story is: the sites most likely to have followed good hardening advice in the past are, for that exact reason, some of the more likely candidates to have had this specific emergency patch silently fail to apply. Add in disabled cron, container images that don't persist filesystem writes, custom deploy pipelines that don't touch core files the way WordPress expects, or auto-updates simply switched off — and "WordPress fixed this automatically" turns out to rest on a lot of assumptions nobody's actually verified per-site.

Even reporting on the disclosure itself has landed on the same conclusion: WordPress has never confirmed whether the forced push reaches sites that had background updates disabled, and the most consistent advice from security researchers covering it isn't "you're covered" — it's check what version is actually running.

What to actually check

This doesn't require a security background:

1. Log into wp-admin and look at the version number on the Dashboard or Updates screen. You need 6.8.6, 6.9.5, or 7.0.2 — not "up to date" as a vibe, the literal number.
2. If it's older, don't wait for it to fix itself. Update manually, right now.
3. Ask whoever hosts or manages the site directly: "did this specific patch apply, and how do you know?" A confident-sounding "we handle updates" is not the same answer as someone who actually checked.

Why this keeps happening

This is the same lesson we keep coming back to on accessibility audits: an automated process gives you confidence, not certainty. A conformance scanner isn't proof a site is accessible. A forced auto-update isn't proof a site is patched. Both need a person to actually verify the outcome, not just trust that the system that was supposed to handle it, handled it.

If your WordPress site is self-managed, on a host you inherited, or you genuinely don't know who's responsible for checking this — that's worth resolving before the next one of these comes along, not during it. See Managed Hosting & Infrastructure for how we run patching so "did it actually apply" has a real answer.