CVE-2026-63030

What is WordPress Core?

WordPress powers roughly 40% of all websites, and its REST API is the backbone that modern themes, plugins, and the block editor all rely on to communicate with the server. A logic bug in the REST API's core request-routing machinery — as opposed to a bug in one plugin's API endpoint — potentially affects every default WordPress installation simultaneously, which is what makes this vulnerability class rare and unusually consequential compared to the plugin-level bugs that make up the bulk of WordPress CVEs.

Overview

CVE-2026-63030 is an interpretation conflict vulnerability (CWE-436) in WordPress Core's REST API batch request handler, present since WordPress 6.9. On its own it lets requests be dispatched to the wrong internal handler; combined with a SQL injection in WP_Query tracked separately as CVE-2026-60137, it forms an unauthenticated remote code execution chain researchers have named "wp2shell." Both were disclosed July 17, 2026 and patched in WordPress 7.0.2 (backported to 6.9.5), with proof-of-concept code and in-the-wild exploitation both following within days — see CVE-2026-60137 on this site for the SQL injection half of the chain and full remediation guidance, which applies to both CVEs together.

Affected Versions

The routing-confusion bug in this CVE was introduced in WordPress 6.9 — sites still on the 6.8.x branch are not affected by this half of the chain, only by CVE-2026-60137.

Technical Details

The flaw lives in WP_REST_Server::serve_batch_request_v1(), which handles the REST API's batch-request endpoint (/wp-json/batch/v1), allowing multiple API sub-requests to be bundled into a single call. The handler validates and dispatches sub-requests using two separate internal arrays that are meant to stay in sync. When a batched sub-request contains a malformed path that causes wp_parse_url() to fail, the resulting error gets recorded only in the validation array — not in the dispatch/matches array — desynchronizing the two. Because of that desync, every subsequent sub-request in the same batch call gets matched against the wrong route handler. An attacker can exploit this "interpretation conflict" to get a request routed to an internal handler that would normally require authentication or wouldn't normally be reachable, landing on the vulnerable WP_Query code path used by CVE-2026-60137's SQL injection — the two flaws together produce unauthenticated SQL injection and remote code execution on default installations, when a persistent object cache is not in use.

Discovery

Discovered by Adam Kues of Searchlight Cyber, who withheld exploit specifics at the initial July 17, 2026 disclosure due to severity, publishing the full technical write-up on July 20. The companion SQL injection (CVE-2026-60137) was reported by researchers TF1T, dtro, and haongo. Kues noted publicly that "no security researcher could have found and completed this exploit chain in 10 hours without AI," describing how quickly a working exploit was reconstructed once the vulnerability details became public.

Exploitation Context

Public proof-of-concept exploits appeared on GitHub within hours of the July 17, 2026 disclosure. Tenable, Rapid7, Akamai, NetSPI, and CyCognito all confirmed in-the-wild exploitation attempts via honeypot telemetry by July 20, 2026, and Cloudflare deployed dedicated WAF rules for the chain given WordPress's scale. CISA added this CVE to KEV on July 21, 2026 with a four-day deadline (July 24) — notably tighter than the August 4 deadline given to the companion CVE-2026-60137, despite the two being exploitable only as a pair.

Remediation

1. Update to WordPress 7.0.2 (or 6.9.5 if you cannot yet move to the 7.0 branch) immediately — this addresses both this routing flaw and the chained SQL injection in CVE-2026-60137.
2. Patch both chained CVEs together regardless of CISA's staggered deadlines — CVE-2026-60137's later August 4 date does not mean it's safe to defer, since the two vulnerabilities are only dangerous when combined.
3. Enable a persistent object cache (Redis or Memcached) as defense-in-depth if immediate patching isn't possible — the chain is specifically noted as reachable only when a persistent object cache is not in use.
4. Deploy WAF rules for malformed REST API batch requests (/wp-json/batch/v1) if your CDN/WAF provider (e.g., Cloudflare) has published coverage for this chain.
5. Review logs for anomalous /wp-json/batch/v1 requests with malformed sub-request paths, and check for unexpected admin accounts, modified core files, or webshells if the site was internet-facing and unpatched between July 17–20, 2026.