Most critical WordPress advisories come with an escape hatch: a vulnerable plugin you can disable, a non-default setting you can check. The chain disclosed in mid-July, informally named wp2shell, does not. It targets WordPress core itself, works against a default installation, and needs nothing more than an anonymous HTTP request to reach code execution.
What the chain actually does
Two separate bugs do the work. The first, CVE-2026-63030, is a batch-route confusion flaw in the REST API that lets a request slip past the authentication boundary the router is supposed to enforce. The second, CVE-2026-60137, is a SQL injection reachable through the author__not_in parameter in WP_Query, rated 9.1 or higher. Individually, each is serious. Chained, they turn an unauthenticated request into arbitrary code execution.
Credit is split across the disclosures. According to The Hacker News, Adam Kues of Assetnote — the attack surface management arm of Searchlight Cyber — found the batch-route bug and reported it through WordPress’s HackerOne program, while researchers going by TF1T, dtro, and haongo reported the SQL injection separately. Searchlight’s own writeup notes the attack carries no preconditions and can be run by an anonymous user.
The exposure window is narrower than it first appears. The full RCE chain only exists from WordPress 6.9 forward, which shipped on 2 December 2025 — so the sites at risk of code execution are running software less than eight months old. Branch 6.8 (through 6.8.5) inherits only the SQL injection. Fixed builds are 6.8.6, 6.9.5, and 7.0.2.
There is one accidental mitigation worth knowing about: sites backed by a persistent object cache such as Redis or Memcached may not be exploitable through this particular chain, per Cloudflare’s analysis. That is a side effect of how the chain reaches the query layer, not a defense anyone designed — and the SQL injection remains a problem regardless.
The patch-to-exploit gap keeps shrinking
WordPress pushed the fixes on a Friday with forced auto-updates enabled. Within about a day, other researchers had read the published patch diff, reconstructed the mechanism, and dropped a working proof-of-concept on GitHub.
That sequence is the operationally relevant part. A patch that ships as readable source is also a disclosure document, and the interval between “fix available” and “exploit available” is now measured in hours for high-value targets. WordPress runs on a very large share of the web — over 500 million sites by common estimates — and prior mass campaigns against less severe, already-patched flaws still compromised sites in the tens of thousands.
For anyone who cannot patch immediately, the interim guidance from the researchers is to block both request paths to the batch endpoint at the WAF layer — /wp-json/batch/v1 and the rest_route=/batch/v1 query form — since blocking only one leaves the other open. Cloudflare shipped WAF rules covering the chain, and Rapid7 authenticated checks for InsightVM and Nexpose were slated for 20 July. As of the initial reporting, the chain was not yet listed in CISA’s Known Exploited Vulnerabilities catalog.
What this means
For practitioners, the checklist is short and unglamorous. Confirm the actual running version on every WordPress property you own, including the marketing microsites and the campaign landing pages nobody has inventoried. Forced auto-update does not cover installations where auto-updates were disabled, which in enterprise fleets is most of them. Then verify — don’t assume — that both batch-route paths are blocked at the edge, and treat any 6.9.x or 7.0.x install that sat unpatched over the weekend as needing a compromise assessment rather than just a version bump.
