Threat Overview
Most WordPress compromises start with something you installed. “wp2shell” requires none of that. Two flaws in WordPress core chain into remote code execution on a default installation: no plugins, no theme, no account, no interaction. The attacker never logs in, because the chain completes before authentication is in play.
| Threat Metric | Technical Details |
|---|---|
| Severity Rating | CRITICAL (CVSS 9.8 for the chain) |
| Vulnerability Class | REST API Batch-Route Confusion (CWE-436) chained to SQL Injection (CWE-89) |
| Vulnerable Components | WordPress Core 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1 |
| Attack Vector | Anonymous request to the public REST batch endpoint /wp-json/batch/v1 |
| Exploitation Status | Public proof-of-concept since July 18, 2026; added to the CISA Known Exploited Vulnerabilities catalog July 21 |
| Fixed Versions | 6.8.6, 6.9.5, 7.0.2 (and 7.1 beta 2) |
The Breakdown: How the Exploit Works
WordPress ships a batch endpoint that lets a client bundle several API calls into one request. The endpoint misaligns each validated call with the handler that ultimately executes it, so an attacker can craft a request whose parts are checked against one route but run against another — walking past the parameter sanitization the rest of the REST API depends on.
Waiting on the other side is a core database query class that accepts a post-listing parameter without verifying it is an array. Unsanitized input reaches the database layer. That is the injection.
Escalation from database read to code execution runs through WordPress’s own object cache and post-processing behavior: the attacker manipulates stored state, assumes an administrative context, and installs a plugin of their choosing. The chain requires that a persistent object cache is not enabled — so a site tuned for performance may be the exposed one.
The Operational Risk: What an Attacker Gains
Full control of the installation, obtained without a single credential. The site can host malware, redirect visitors, harvest card data, or serve as a launching point against other systems. Because the entry point is core code rather than an add-on, every check built around plugin inventories and license lists is blind to it.
Our Take in Plain English
“This is the case that ends the ‘we keep our plugins updated’ conversation. You can audit every add-on you run, patch the moment a fix ships, and still be exposed by the foundation everything sits on. The lesson is not that core is careless — it is that anything running code on demand at the edge grows an attack surface with every feature. A pre-rendered site pays no such tax: there is no query to inject, no endpoint to confuse, and nothing to execute, because the pages are already built.”
The Modern Architectural Remedy
- Legacy Dynamic Platform: Exposes an application server that answers requests by querying a database at runtime, placing query construction within reach of the public internet.
- Modern Pre-Rendered Architecture: Publishes finished pages to a global edge network. There is no runtime database connection and no code path for a crafted request to reach.
Immediate Action Items for WordPress Operators
- Confirm the version actually installed. WordPress force-pushed updates to affected sites, creating a dangerous assumption — a silent background update can fail, and some hosting stacks disable it entirely. Check the reported version rather than trusting the notice.
- Take 6.9.0 and later seriously. The full chain requires 6.9 or newer. Sites on 6.8.x still need the injection fix, but are not exposed to the complete attack.
- Block the endpoint while you work: Deny traffic to
/wp-json/batch/v1and?rest_route=/batch/v1, covering both patterns — a firewall rule matching only one leaves the fast path open. - Review anything that ran exposed: Inspect administrator accounts, installed plugins, uploads, and logs. Where integrity cannot be confirmed, restore from a known-clean backup.