By WordPress released security updates on July 17 — versions 7.0.2, 6.9.5, and 6.8.6. This is not a routine maintenance release. Researchers at Assetnote disclosed a pre-authentication remote code execution flaw in WordPress core that requires no credentials, no plugins, and no non-default configuration. An anonymous HTTP request is enough to trigger it on a stock install. The technical details and a working proof-of-concept went public on July 18. If you are running WordPress 6.9.x or 7.0.x and have not updated, do that before reading the rest of this.
What Is wp2shell
The exploit is nicknamed wp2shell and chains two CVEs: CVE-2026-63030 (CVSS 9.8 Critical — the REST API route confusion) and CVE-2026-60137 (the underlying SQL injection in WP_Query). The name is blunt on purpose: shell access with no authentication. WordPress powers roughly 43% of the web, and the vulnerable endpoint has shipped enabled by default since WordPress 5.6 in December 2020. Scope does not get much broader than this.
How the Exploit Chain Works
The flaw lives in WP_REST_Server::serve_batch_request_v1(), the handler for the batch endpoint at /wp-json/batch/v1. This endpoint lets callers bundle multiple REST sub-requests into a single HTTP call — a performance feature used by Gutenberg and headless WordPress setups.
The handler tracks sub-requests across three parallel arrays: $requests, $validation, and $matches. They must stay in sync. They do not. When a sub-request fails early parsing, the error is appended to $validation[] but not to $matches[]. That creates a permanent one-element offset. Every subsequent sub-request in the batch is then dispatched against the route and permission callback that belong to the next entry — not its own.
An attacker exploits this by sending a deliberately malformed first request (something as simple as the URL http:) to trigger the desync. The second request then executes under a different handler’s permission check. That confusion delivers the attacker’s payload to WP_Query without authentication, where a string passed to the author__not_in parameter bypasses array validation and drops raw SQL into the query. The public proof-of-concept demonstrates reading the database — including admin password hashes. The researchers at Searchlight Cyber have withheld the final step from hash dump to full code execution, but that step involves standard techniques and will not stay private long.
Are You Affected
| Branch | Affected Range | Fixed In |
|---|---|---|
| 6.8.x | 6.8.0 – 6.8.5 | 6.8.6 (SQL injection only, not full RCE) |
| 6.9.x | 6.9.0 – 6.9.4 | 6.9.5 |
| 7.0.x | 7.0.0 – 7.0.1 | 7.0.2 |
| < 6.8.0 | Not affected | — |
Versions before 6.8 do not contain the vulnerable code path and are not affected by either CVE.
How to Fix It
Update. That is the fix. Everything else is a workaround.
WordPress.org pushed forced automatic updates to affected sites, but automatic does not mean confirmed. Go to Dashboard → Updates and verify your version number is 7.0.2, 6.9.5, or 6.8.6 before assuming you are clear. For WP-CLI users:
wp core update
wp core versionIf you manage WordPress via Composer or a version-controlled deployment pipeline, auto-updates are likely disabled — pull the patch manually. Managed hosting providers (WP Engine, Kinsta, Pressable) have generally applied the update at the platform level, but verify through your dashboard regardless.
If You Cannot Patch Right Now
Block the batch endpoint at your WAF or web server. You need to cover both forms:
/wp-json/batch/v1
?rest_route=/batch/v1Searchlight Cyber also released a drop-in mitigation plugin at wp2shell.com that rejects anonymous batch requests without a full update. Use it as a bridge, not a destination. These workarounds may break Gutenberg’s block editor for some configurations and any headless frontend that uses the batch endpoint — test before deploying to production.
Where Things Stand
As of July 18, no confirmed in-the-wild exploitation has been reported. The public proof-of-concept on GitHub demonstrates database read and credential harvesting, not yet full shell execution. That gap is narrowing. Rapid7 noted that AI-assisted code analysis accelerates weaponization of public PoC code, and estimated a fully working exploit is likely within days of disclosure.
The framing from Security Boulevard is worth holding onto: the question is not whether your site has the vulnerable version. The question is which of your instances an attacker can reach right now. If you manage a portfolio of WordPress sites, that inventory problem is now urgent. Run the free scanner at wp2shell.com if you need a fast read on your exposure before you can patch everything.
July 2026 has been a heavy month for security patches — Next.js patched nine vulnerabilities, Rust shipped an LLVM miscompilation fix, and now this. The pattern is not coincidence; it is the normal rhythm of a maturing ecosystem taking security seriously. Patch fatigue is real, but wp2shell is the one on this list where waiting is not a reasonable position.
