wp2shell: A Rare WordPress Core RCE Chain, Built in Hours, Aimed at 40% of the Web

A Bug in Core, Not a Plugin

The overwhelming majority of WordPress CVEs live in the plugin and theme ecosystem — tens of thousands of third-party extensions of wildly varying code quality, patched (or not) on each developer's own schedule. WordPress Core itself, the codebase that ships with every install regardless of which plugins are active, is comparatively small, heavily reviewed, and rarely the source of a critical vulnerability. That rarity is exactly what makes CVE-2026-63030 and CVE-2026-60137 — two Core bugs disclosed together on July 17, 2026 and nicknamed "wp2shell" by the researchers who found them — worth a closer look than the usual plugin-of-the-week file-upload flaw. WordPress runs roughly 40% of all websites. A Core bug doesn't need a popular plugin installed to matter; it just needs a default installation.

The Chain, Piece by Piece

Neither bug is catastrophic entirely on its own, which is part of why the pair is instructive.

CVE-2026-63030 (CWE-436, "interpretation conflict") lives in WP_REST_Server::serve_batch_request_v1(), the handler behind the REST API's batch-request endpoint at /wp-json/batch/v1, which lets a caller bundle multiple API sub-requests into a single call. The handler tracks sub-requests in two parallel internal arrays — one used for validation, one used for dispatch — that are supposed to stay in lockstep. When a batched sub-request contains a path malformed enough to make wp_parse_url() fail, the resulting error is recorded only in the validation array. The dispatch array doesn't get the memo. From that point on, every subsequent sub-request in the same batch call is matched against the wrong route handler — an "interpretation conflict" between two code paths that are supposed to agree on what a given request means but don't. Introduced in WordPress 6.9.

CVE-2026-60137 (CWE-89, SQL injection) lives in WP_Query, in how the author__not_in parameter gets built into a SQL query. On its own, this parameter isn't reachable by an unauthenticated request — it sits behind a code path that assumes some prior authorization has already happened. Introduced in WordPress 6.8, one release earlier than the routing bug.

Chained, the two produce something neither does alone: the routing confusion misdirects a request to the internal handler that touches the vulnerable WP_Query path, and the SQL injection there gives an unauthenticated attacker a route to remote code execution on a default WordPress installation — provided a persistent object cache (Redis, Memcached) isn't in use, which is the default state for most sites. Two moderate-looking primitives, wired together by a state-desync bug, produce a Critical.

Why the Deadlines Don't Match the Chain

CISA added both CVEs to KEV on July 21, 2026 — but with different remediation deadlines. CVE-2026-63030 got four days, due July 24. CVE-2026-60137 got until August 4, nearly two weeks longer. That's an unusual outcome for two vulnerabilities that are, by the researchers' own description, only dangerous together. A defender who reads the deadlines literally and treats August 4 as "less urgent" is making a decision the vulnerability itself doesn't support: patching only CVE-2026-63030 by the earlier deadline still leaves the SQL injection reachable through whatever routing path existed before the batch-handler bug, and patching only CVE-2026-60137 leaves an attacker able to reach other Core paths through the same routing desync for other purposes. The single fix for both — WordPress 7.0.2, or the 6.8.6/6.9.5 backports — should be applied on the tighter of the two deadlines, not the looser one. Treating a chain's component CVEs as independently prioritizable, just because they were assigned separate IDs and separate deadlines, is a mistake worth generalizing beyond this specific pair.

Ten Hours, and the AI Line Worth Sitting With

Adam Kues of Searchlight Cyber, who found and reported CVE-2026-63030, deliberately withheld exploitation specifics at the initial July 17 disclosure given the severity, publishing a full technical breakdown three days later. In discussing how quickly a working exploit chain came together once details were public, Kues was quoted saying "no security researcher could have found and completed this exploit chain in 10 hours without AI."

Read narrowly, that's a comment about one researcher's workflow. Read as a trend, it's consistent with what this site's companion analysis of KEV time-to-exploitation already documented: across a two-week window of July 2026 KEV additions, six of nine CVEs had effectively zero gap between patch availability and confirmed exploitation. That piece attributed most of the speed to automated scanning infrastructure primed to fire the moment an advisory drops. wp2shell adds a second, related mechanism to the picture — AI-assisted exploit construction itself compressing what used to be a multi-day reverse-engineering effort (reconstruct the bug from a patch diff, build a working chain, test it) into a single working day. If that compression generalizes beyond this one researcher's account of this one chain, the "time to first exploit" side of the vulnerability-management equation gets faster on both ends at once: automated scanners waiting to pounce, and the exploits they're running increasingly assembled in hours rather than days by whoever gets there first — attacker or researcher.

What Confirmed the Severity Fast

Public proof-of-concept code appeared on GitHub within hours of the July 17 disclosure. By July 20, Tenable, Rapid7, Akamai, NetSPI, and CyCognito had all independently confirmed in-the-wild exploitation attempts via honeypot telemetry — a three-day gap from disclosure to multi-vendor confirmed exploitation, on infrastructure that runs 40% of the web. Cloudflare shipped dedicated WAF rules for the pair given the scale of potentially affected sites, one of the clearer signals that a WordPress Core bug (rather than a single plugin) was in play: CDN/WAF providers don't usually build bespoke rule sets for individual plugin vulnerabilities at this speed, but a bug reachable on every default install justifies the engineering effort.

What to Do

1. Update to WordPress 7.0.2 (or the 6.8.6 / 6.9.5 backports if you can't move to the 7.0 branch yet) — one update addresses both halves of the chain, and there is no reason to patch them separately.
2. Ignore the deadline gap between the two CVEs when prioritizing — patch both on whichever timeline is tighter. A chain is only as slow as its faster-moving half.
3. Enable a persistent object cache (Redis or Memcached) as defense-in-depth if immediate patching isn't possible — the exploitable path is specifically gated on a persistent object cache not being in use, which is the out-of-the-box state for most WordPress installs.
4. Turn on WAF coverage for malformed REST API batch requests if your CDN or WAF vendor has shipped rules for this pair (Cloudflare has).
5. Check logs for /wp-json/batch/v1 requests with malformed sub-request paths covering July 17 onward, and look for unexpected admin accounts, modified core files, or webshells on any site that was unpatched and internet-facing during that window.
6. Stop treating multi-CVE chains as independently schedulable work items. If a vendor advisory or KEV addition describes two CVEs as chained, the remediation plan should treat them as one ticket with one (the earlier) deadline, regardless of how CISA or the vendor scored each half individually.

The Broader Point

wp2shell is a useful case study less because of its individual technical cleverness — a routing-array desync and a query-builder SQLi are both familiar bug classes — and more because of what it demonstrates about compound risk and remediation planning. Two vulnerabilities, each moderate or serious in isolation, became critical only in combination; the organizations that patch by severity score per-CVE rather than by understanding the dependency between CVEs are the ones left exposed on the vulnerability that "only" scored a 5.9. And a researcher's own account of how fast the chain went from disclosure to working exploit — hours, with AI assistance — is a preview of a vulnerability-management environment where the exploit-development side of the clock, not just the scanning side already documented in our time-to-exploitation piece, keeps getting faster.