A new WordPress core exploit chain, now widely tracked as wp2shell, is being actively used against internet-facing WordPress sites. It doesn’t need a vulnerable plugin, a valid login, or any user interaction – just a reachable WordPress REST API. That combination is why it’s spreading fast, and why it deserves more attention than a routine CVE.
Here’s what wp2shell is, how it’s being used in the wild, and what to do about it right now.
What Is wp2shell?
wp2shell isn’t one bug – it’s two, chained together.
CVE-2026-63030 is a route-confusion flaw in WordPress core’s REST API batch endpoint (
WP_REST_Server::serve_batch_request_v1()). When several sub-requests are processed in one batch call, an error in one request can desynchronize the tracking arrays behind the scenes, causing a request to be handled by the wrong route. Nested carefully, this lets an attacker’s input walk past access controls that would normally block it. Rated High (CVSS 7.5) on its own.
CVE-2026-60137 is a SQL injection in the
author__not_inparameter ofWP_Querythe class that builds most of WordPress’s database queries. Rated Critical (CVSS 9.1) on its own, but it normally requires a code path that isn’t reachable by an anonymous visitor. - Note on severity: Published ratings for the combined chain vary — individual CVEs score 9.1 and 7.5, while combined-chain assessments range from 7.5 to 9.8 depending on the source. The number matters less than the operational reality: unauthenticated, remote, and no plugin required. Treat it as critical.
Chained together, the batch-route confusion gives an unauthenticated attacker a way to smuggle a request into the vulnerable SQL injection path — no login, no plugin needed. Two flaws, on their own, become a pre-authentication remote code execution path when combined.
How Attackers Are Using wp2shell
Observed activity shows the chain used in stages, not as a single clean exploit:
-
Recon - Probing
/wp-json/batch/v1or the query-string equivalent?rest_route=/batch/v1to fingerprint vulnerable versions. -
Exploitation - A nested, recursive batch request smuggles a SQL injection payload through the
author__not_in/author_excludeparameters, extracting data the attacker shouldn't access - most notably, administrator password hashes. -
Escalation - Cracked credentials are used to log in normally and upload a malicious plugin or theme file - the "shell" in wp2shell. Some public exploit variants skip credential cracking entirely, forging a new administrator account directly via
customize_changesetand oEmbed object hydration, making this a native code-execution chain rather than mere information disclosure.
The SQL injection itself is read-only – it doesn’t directly execute code. Full compromise depends on the second step: turning stolen credentials into a code-execution foothold through legitimate admin functionality (plugin/theme upload). That’s useful for defenders, because it means there’s more than one place to stop the attack.
Public proof-of-concept tooling is already circulating, and exploitation attempts have picked up quickly since disclosure. As of July 21, 2026, multiple independent security firms have confirmed active in-the-wild exploitation.
Who's Exposed to the wp2shell Vulnerability?
The full chain affects WordPress core 6.9.0–6.9.4 and 7.0.0–7.0.1. A narrower band, 6.8.0–6.8.5, carries only the SQL injection component and isn’t exposed to the complete unauthenticated RCE path – but it still needs patching, since that distinction easily gets lost in scan reports that just flag “vulnerable” or “not vulnerable.”
Because the entry point is WordPress core rather than a plugin, no add-ons are required for a site to be exposed. A lean, well-maintained install is just as reachable as a heavily customized one. Given how widely WordPress is deployed – corporate sites, campaign microsites, subsidiary properties, and older installs still online but rarely revisited – the exposed population is large and unevenly monitored.
Affected and Fixed Versions At a Glance
Stopping wp2shell at the WAF Layer
This chain is well-suited to WAF interruption because it has two distinct, observable stages before credential theft ever occurs:
-
Unusual endpoint traffic: Legitimate front-end traffic rarely calls
/wp-json/batch/v1directly, so restricting or closely monitoring that endpoint is a low-collateral-damage control. -
Recognizable payload shape: SQL keywords inside
author__not_in/author_excludeparameters aren't something normal site traffic produces. - Tooling fingerprints: Publicly circulating exploit frameworks carry identifiable user-agent strings, making signature-based detection meaningfully effective - at least until tooling evolves to evade it.
Concrete indicators of compromise (IOCs):
-
HTTP
207/200Multi-Status responses to batch-endpoint requests - a high-fidelity sign of successful exploitation. -
User-agent strings containing
"wp2shell"or"rezwp2shell"- flags for purpose-built exploitation frameworks.
Recommended layered defense, regardless of WAF vendor:
- Block or gate the batch endpoint.
- Add pattern detection for injection attempts on the specific parameters involved.
- Watch for known tooling fingerprints as a high-confidence trigger for immediate investigation.
This is the layered approach we’d recommend regardless of which WAF you’re running: block or gate the batch endpoint, add pattern detection for injection attempts on the specific parameters involved, and watch for the known tooling fingerprints as a high-confidence trigger for immediate investigation.
Where Prophaze Fits In
Prophaze’s WAAP is powered by an AI/ML detection engine built around anomaly detection, positive-security, and virtual-patching models, and already provides coverage against the entry point of this attack chain. Because wp2shell begins with an unauthenticated SQL injection, Prophaze’s engine identifies and blocks the malicious request that anchors the chain – catching anomalous access to internal API routes, injection patterns in request parameters, and known-bad client fingerprints as they emerge, without waiting on a static signature or downstream patch.
Customers with injection protection enabled have baseline coverage against the core of this threat today.
Beyond that baseline, Prophaze’s engine continuously learns normal traffic patterns and adapts to anomalous batch-endpoint behavior and novel variants of this chain, rather than relying solely on static signatures. Blocking the injection breaks the chain before it can escalate to credential theft or admin-account creation – backed 24×7 by our security team.
If you’re a Prophaze customer, your account team can confirm coverage for your specific deployment and help layer in the endpoint restrictions above where needed.
Recommended Actions Checklist
For Prophaze customers, the WAAP coverage above is already working to contain this chain while you complete the steps below. Patching remains the only permanent fix – treat these as the priority; the WAAP buys a safe window to get there.
- Inventory every internet-facing WordPress instance and confirm the running core version.
- Prioritize patching anything on 6.9.0+ - the full unauthenticated RCE chain.
- Don't skip 6.8.x sites - they still need 6.8.6 for the SQL injection component.
-
Restrict or closely monitor
/wp-json/batch/v1and its query-string equivalent at the WAF layer until patched.
Have questions about how this applies to your environment? Reach out to the Prophaze team to talk through your exposure and current rule coverage.
Frequently Asked Questions (FAQ)
1. What is wp2shell?
wp2shell is the name given to a chained exploit combining CVE-2026-63030 (a WordPress REST API batch-endpoint route-confusion bug) and CVE-2026-60137 (a SQL injection in WP_Query), enabling unauthenticated remote code execution on vulnerable WordPress core installs.
2. Which WordPress versions are affected by wp2shell?
WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1 are exposed to the full unauthenticated RCE chain. WordPress 6.8.0–6.8.5 is exposed only to the SQL injection component, not the full chain.
3. Does wp2shell require a vulnerable plugin?
No. The vulnerability is in WordPress core itself, so no plugins are required for a site to be exposed.
4. How do I fix wp2shell?
Update to WordPress 6.9.5, 7.0.2, or 7.1 Beta 2 (depending on your branch), or 6.8.6 if running the 6.8.x series. Until patched, restrict or monitor
/wp-json/batch/v1at the WAF layer.
5. How can I detect wp2shell exploitation attempts?
Watch for HTTP 207/200 Multi-Status responses on batch-endpoint requests and user-agent strings containing “wp2shell” or “rezwp2shell.”
