wp2shell: Pre-Auth RCE in WordPress Core — Check Your Version Now

On July 17, 2026, WordPress released emergency patches for a two-CVE attack chain researchers are calling wp2shell: a pre-authentication remote code execution vulnerability in WordPress Core itself. No plugins, no server misconfiguration, no user interaction — an anonymous HTTP request to a stock WordPress install is enough for an attacker to take full control of the site and its underlying server. A working proof-of-concept was published on GitHub on July 18, and mass scanning will follow quickly.

The Attack Chain, Explained

CVE-2026-60137 is a SQL injection in WP_Query, the core class behind virtually every database query WordPress runs. The trigger is the author__not_in parameter: when a string arrives where WordPress expects an array, an is_array() sanitization guard is skipped and the raw value gets interpolated directly into a SQL NOT IN (...) clause. Dangerous on its own — but in a typical install, reaching this parameter as an unauthenticated user requires a separate door.

CVE-2026-63030 is that door. WordPress has shipped a REST API batch endpoint at /wp-json/batch/v1 since version 5.6 in December 2020, letting authenticated clients bundle multiple REST requests into one roundtrip. The vulnerability is in how the batch processor tracks three parallel arrays to manage sub-request state. When one sub-request fails validation, an error is appended to the validation array but not the matches array — throwing the two out of alignment by one index. Every subsequent sub-request in the batch then gets evaluated with the route and permission callback belonging to the next entry in the queue, effectively bypassing its own authentication check entirely.

Chain them together: an attacker sends a crafted batch request, lets one sub-request fail to trigger the index shift, and arrives at the WP_Query SQL injection path with its permission check silently bypassed. From SQL injection the path to remote code execution involves dumping the database to crack an admin password hash, then establishing a webshell — all from a single unauthenticated HTTP POST.

Adam Kues of Assetnote (Searchlight Cyber's research arm) discovered and reported the batch-route flaw via WordPress's HackerOne program. The SQL injection (CVE-2026-60137) was independently identified by researchers TF1T, dtro, and haongo. One technical nuance worth noting from Cloudflare's analysis: the exploit path requires no persistent object cache to be active on the target server. Sites already running Redis or Memcached get a partial technical mitigation — though that's not a substitute for patching, and it's not how you want to discover your object cache is configured correctly.

Exactly Which Versions Are Exposed

The full pre-auth RCE chain requires WordPress 6.9.0 or later — the December 2, 2025 release that introduced the vulnerable batch endpoint behavior. That means roughly seven months of production installs are in scope for worst-case exploitation. Sites running the 6.8.x branch face the SQL injection bug but not the full pre-auth RCE path, because the batch endpoint behavior required to bypass authentication is not present in that branch.

• WordPress 6.9.0 – 6.9.4: vulnerable to full pre-auth RCE chain → update to 6.9.5
• WordPress 7.0.0 – 7.0.1: vulnerable to full pre-auth RCE chain → update to 7.0.2
• WordPress 6.8.0 – 6.8.5: vulnerable to CVE-2026-60137 (SQL injection) only, no pre-auth RCE → update to 6.8.6
• WordPress 6.7.x and earlier: not affected by either CVE

About Those CVSS Scores

If you search NVD for CVE-2026-63030 and see conflicting numbers, here is why. WPScan, the CNA that assigned the CVE, scored it 9.8 Critical — reflecting the full RCE chain impact: network-accessible, no authentication required, no user interaction, complete compromise of confidentiality, integrity, and availability. CISA's Automated Discovery Program issued a supplemental score of 7.5 High, modeling only the confidentiality impact of the REST API bug considered in isolation. The 9.8 score is the more accurate representation of what this chain produces against a real target. Security teams briefing leadership should use 9.8 and expect questions about the gap.

What to Do Right Now

WordPress.org enabled forced automatic updates for affected installations on July 17, and Cloudflare deployed WAF blocking rules targeting the wp2shell exploit path the same evening. Active exploitation has not been confirmed in CISA's Known Exploited Vulnerabilities catalog as of July 18 — but mass scanning for vulnerable installs will start within hours of a public PoC, not days. Don't wait to find out which side of that window you're on.

• Verify your WordPress version directly. Check /wp-includes/version.php or look in wp-admin under Dashboard > Updates. Do not assume the forced auto-update succeeded — some hosting configurations, permission setups, or locked environments prevent WordPress from writing its own core files, and auto-update failures are silent.
• Check every WordPress install you own. Staging environments, dormant subdomains, and development instances are commonly overlooked and commonly unpatched. They're also commonly exploited precisely because they're overlooked.
• Review your access logs for batch endpoint traffic. Look for unusual POST requests to /wp-json/batch/v1 (or /?rest_route=/batch/v1) starting from July 17. Batch API requests are rare on most business sites; anything unexpected warrants investigation.
• Confirm WAF coverage if patching is delayed for any reason. Cloudflare's managed WordPress ruleset now includes a blocking rule for CVE-2026-63030 (rule IDs 7dfb2bd4708d4b88b9911dc0550664b6 and ebd3f2df15c74ddcbf6220c9b5ec246a for managed and free tiers respectively). Other WAF providers have deployed equivalent coverage. Verify rules are set to block, not log.
• Add a persistent object cache if you haven't. Redis or Memcached integration closes the specific exploit path for wp2shell and delivers substantial database query performance gains. It's a rare case where a security hardening measure also makes your site meaningfully faster.

At Falcon Internet, wp2shell is precisely the kind of event our 24x7x365 NOC monitors for — within hours of the July 17 release, we had confirmed WordPress Core version status across managed customer sites and flagged any installs where auto-update had not yet applied. For any site owner relying on manual monitoring: the gap between patch release and active mass scanning is measured in hours now. That gap does not leave much room for waiting until Monday.