Invalid Date

WP2Shell: While Everyone Watched AI, a Pre-Auth RCE Ate WordPress Core

A boring, pre-authentication RCE in the world's most popular CMS is being mass-exploited right now. Here's how WP2Shell works and exactly what to do today.

By
WP2Shell: While Everyone Watched AI, a Pre-Auth RCE Ate WordPress Core

AI Security Series · Part 9

Our last two posts followed AI into the threat model. Part 7 argued your AI coding tools are now an attack surface. Part 8 watched the AI itself become the attacker. This one is a deliberate step back to earth: while the industry stares at AI-versus-AI, a plain, pre-authentication remote code execution bug in the world's most popular CMS is being mass-exploited right now. No model, no prompt injection — just a decades-old class of flaw in software that runs a huge share of the web.

It's called WP2Shell, and if you run WordPress you should stop reading and check your version first.

What WP2Shell actually is

WP2Shell is not one bug — it's a chain of two, and neither is a plugin. Both live in WordPress core:

  • CVE-2026-63030 — a logic flaw in the REST API batch processor (WP_REST_Server::serve_batch_request_v1(), introduced in WordPress 6.9). The validation loop and the execution loop desynchronize, so a request that looks valid on the way in gets a rogue parameter smuggled through to execution.
  • CVE-2026-60137 — a SQL injection in the author__not_in parameter of WP_Query, present since WordPress 6.8.

Chained, an unauthenticated attacker hits /wp-json/batch/v1, the batch route confusion slips the poisoned parameter into WP_Query, the SQL injection fires, and the chain drives toward code execution on the server.

The uncomfortable part is the preconditions: there are none. It works against a default WordPress install with zero plugins, no login, and no user interaction. That's what makes the exposure so large — this isn't a niche add-on, it's the platform itself.

Why it's a five-alarm fire this week

The discovery came from Adam Kues at Assetnote (Searchlight Cyber), reported responsibly through WordPress's HackerOne program. But once patches shipped, the situation escalated fast:

  • Public PoC exploits are circulating on GitHub, and full-chain proof-of-concept code has fueled mass scanning across the internet.
  • In-the-wild exploitation was confirmed on July 20 via honeypots — this is no longer theoretical.
  • CISA added both CVEs to its Known Exploited Vulnerabilities catalog on July 21, which for U.S. federal agencies starts a remediation clock.
  • Confirmed attacker behavior includes creating rogue admin accounts, installing malicious plugins, dropping backdoors and webshells, enumerating users, and stealing database credentials and secrets.

Read that last point again. The "shell" in WP2Shell is literal — attackers are landing persistent webshells. If your site was exposed and unpatched during this window, the right assumption is not "am I vulnerable" but "am I already compromised."

Affected versions — and the fix

  • Vulnerable: WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1
  • Fixed: WordPress 6.9.5 and 7.0.2 (also 7.1 Beta 2)

Given the severity, the WordPress.org security team enabled forced auto-updates to push affected sites onto the patched releases. That's good — but "auto-update was enabled globally" is not the same as "auto-update actually applied on your box." Sites with auto-updates disabled, locked file permissions, or non-standard deployments can silently miss it. Verify, don't assume.

What to do today

  1. Check your version. Anything in 6.9.0–6.9.4 or 7.0.0–7.0.1 is vulnerable.
  2. Patch to 6.9.5 or 7.0.2 immediately if you haven't.
  3. Confirm the forced auto-update actually landed. Look at the real running version, not the setting.
  4. Block the batch route at your WAF — both forms. This is the detail most coverage misses, and it matters: a rule that only covers /wp-json/batch/v1 leaves the query-string route ?rest_route=/batch/v1 wide open. Searchlight is explicit that both must be blocked. And a WAF is a stopgap, not a substitute — these are emergency temporary measures until you patch.
  5. Hunt for indicators of an existing compromise: unexpected administrator accounts, plugins you didn't install, unfamiliar files (webshells) under wp-content, and unusual outbound connections or POSTs to /wp-json/batch/v1 in your access logs.

The point of the series

Parts 7 and 8 were about the frontier — AI as attack surface, AI as attacker. WP2Shell is the counterweight. The vulnerabilities that actually take down sites at scale are still, overwhelmingly, the unglamorous ones: a desynchronized loop and a SQL injection in a parameter almost nobody thinks about, in software running a large fraction of the web. Watch the AI horizon, absolutely — but patch the boring, pre-auth RCE first, because that's the one being sprayed across the internet today.

Sources: Rapid7, Searchlight Cyber (original research), The Hacker News, SecurityWeek, and Wiz.

Need help checking whether your WordPress site is patched — or whether it's already been touched? Talk to Sid Techno and we'll audit your stack.

#cybersecurity#sidtechno#web development