wp2shell WordPress RCE: Patch Now

wp2shell WordPress RCE is now a two-CVE chain in CISA’s Known Exploited Vulnerabilities catalog — and it lets a completely unauthenticated attacker execute code on a default WordPress install with no plugins involved. If you run self-hosted WordPress and haven’t confirmed the July 17 auto-update landed, check today.

What Happened

wp2shell WordPress RCE combines two WordPress core flaws: CVE-2026-63030, a logic bug in the REST API batch processor, and CVE-2026-60137, a SQL injection in the author__not_in parameter of the Posts endpoint. WordPress validates and executes batch sub-requests in separate loops; when a malformed sub-request path fails URL parsing, the resulting error lands in the validation array but not the matched-routes array. That desynchronization lets a crafted batch request reach a handler that should never have passed validation, and the chained SQL injection turns that access into full remote code execution — no login, no plugin required.

Affected versions are WordPress core 6.9.0–6.9.4 and 7.0.0–7.0.1, patched in 6.9.5 and 7.0.2 on July 17. WordPress pushed the fix through its forced auto-update system the same day. Despite that, multiple public proof-of-concept exploits — including a published exploit toolkit — surfaced within days, and both CVE-2026-63030 and CVE-2026-60137 were added to CISA’s KEV catalog on July 21 with confirmed in-the-wild exploitation, including credential exfiltration and web shell deployment on sites that missed the update.

Why It Matters

WordPress powers a disproportionate share of small-business websites across the DACH region, and a large fraction of those installs are self-hosted and unmanaged — nobody is watching whether the forced auto-update actually applied. A pre-auth RCE chain in WordPress core itself, rather than in a plugin, is rare and severe: it affects every site running an in-range version regardless of which plugins or themes are installed. For any organization using WordPress for a marketing site, customer portal, or e-commerce storefront, this is a same-day check, not a quarterly review item.

What You Should Do Now

1. Confirm your WordPress core version is 6.9.5, 7.0.2, or later — do not assume the forced auto-update succeeded; verify it manually in the dashboard or via wp-cli (wp core version).
2. If you manage multiple WordPress sites (agencies, hosting resellers), script a version check across your full portfolio today rather than site-by-site.
3. Where immediate patching isn’t possible, block or rate-limit requests to /wp-json/batch/v1 at the WAF or reverse proxy as a compensating control.
4. Review recent admin user creation, unexpected plugin or theme file changes, and web server logs for POST requests to the batch REST endpoint since July 17.

DIESEC Perspective

This is the same pattern DIESEC flagged with Ghost CMS and Drupal earlier this year: the biggest single-platform risk isn’t the exploit’s sophistication, it’s the sheer number of unmanaged, self-hosted installs that never see the patch. wp2shell’s forced auto-update is a good vendor response — but “forced” only works if the update mechanism itself is still functioning on a given server.

Not sure whether every WordPress site your organization runs is actually patched? Contact DIESEC for a rapid WordPress fleet exposure check and patch verification.

Sources: The Hacker News | BleepingComputer
Published: 2026-07-24 | Category: Vulnerabilities & Patches | ~4 min read