wp2shell: Pre-Auth RCE in WordPress Core (CVE-2026-63030 & CVE-2026-60137) — Patch to 7.0.2 Now

On July 17, 2026, researchers at Assetnote and Searchlight Cyber disclosed wp2shell — a pre-authentication remote code execution chain in WordPress Core that requires no account, no plugin, and no non-default configuration to exploit. A single anonymous HTTP request against a stock WordPress installation is sufficient to run attacker-controlled code on the underlying server.

WordPress powers an estimated 500 million websites globally. For a vulnerability that lives in the core platform's default REST API endpoint, the exposed population is difficult to overstate. Active exploitation was confirmed by PatchStack within hours of disclosure on July 17, and mass webshell deployment campaigns targeting vulnerable installations have been observed in the wild. If your WordPress instance is on version 6.9.0–6.9.4 or 7.0.0–7.0.1 and has not yet been updated, it is actively being scanned and potentially compromised right now.

The Two CVEs Behind wp2shell

wp2shell is not a single bug. It is a two-CVE chain where the first vulnerability becomes unauthenticated only when combined with the second.

CVE-2026-60137 (CVSS 9.1 — Critical): SQL Injection in WP_Query

The first link in the chain is a SQL injection in the author__not_in parameter of WordPress's internal WP_Query class — the database abstraction layer used by virtually every WordPress query operation. Under normal conditions, the vulnerable code path is only reachable by authenticated users. WordPress's access controls gate it behind login. In isolation, CVE-2026-60137 is serious but its reach is limited. It affects WordPress 6.8.0 through 6.8.5, 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1, and is patched in 6.8.6, 6.9.5, and 7.0.2.

CVE-2026-63030 (CVSS 7.5 — Critical): REST API Batch Route Confusion

The second link is a logic flaw in WordPress's REST API batch endpoint at /wp-json/batch/v1. This endpoint, introduced to allow multiple API operations in a single HTTP request, is part of WordPress Core, enabled by default, and publicly reachable without authentication. The flaw causes internal batch bookkeeping to lose alignment under specific error conditions, associating a subrequest with a route handler context it does not belong to. On its own, the route confusion does not execute arbitrary code. Combined with CVE-2026-60137, it does something more dangerous: it strips the authentication gate from the SQL injection path.

How the Exploitation Chain Works

The full attack requires no account, no plugin, and no misconfiguration. An attacker constructs a crafted batch request and delivers it to /wp-json/batch/v1 on any unpatched WordPress installation. The route confusion in CVE-2026-63030 causes internal state misalignment. A subrequest is processed in the wrong handler context, bypassing the authentication check that normally protects the CVE-2026-60137 code path. Attacker-controlled input reaches the author__not_in SQL construction code. From SQL injection, the chain progresses to remote code execution on sites that do not have a persistent object cache configured.

That last condition — the absence of a persistent object cache — is a meaningful distinction. Sites running Redis, Memcached, or another persistent cache have the RCE progression blocked; they remain vulnerable to SQL injection (which is serious on its own) but the chain does not reach code execution. The majority of self-hosted WordPress installations do not run a persistent object cache, which is why the exploitable population is so large.

The researcher Adam Kues of Assetnote and Searchlight Cyber has withheld full technical exploitation details to give defenders time to patch. However, PoC exploit code is already in circulation, and the first confirmed in-the-wild exploitation was reported by PatchStack at approximately 7 PM ET on July 17 — the same day as disclosure. Mass webshell deployment campaigns (tracked internally as WP-SHELLSTORM) targeting WordPress installations have since been observed.

Affected Versions at a Glance

The full unauthenticated RCE chain applies to WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. The SQL injection component alone (CVE-2026-60137) extends back to 6.8.0 through 6.8.5, which means sites on older 6.8.x releases are not exposed to unauthenticated RCE but are still vulnerable to authenticated SQL injection.

Fixed versions: 7.0.2 (for 7.x installs) and 6.9.5 (for 6.9.x installs). A backport to 6.8.6 addresses the SQL injection component for sites on the 6.8 branch. WordPress has enabled forced automatic updates across affected installations, but auto-updates are not always reliable on managed hosting environments, customised installs, or sites where updates have been disabled.

Immediate Remediation Steps

Step 1: Update to WordPress 7.0.2 or 6.9.5 right now. Check your running version in the WordPress admin dashboard at Dashboard → Updates. If the forced auto-update has already applied, verify the version number. If it has not, apply it manually. This is the only complete fix.

Step 2: If you cannot patch immediately, block the batch endpoint at your WAF. Searchlight Cyber recommends blocking requests to /wp-json/batch/v1 and ?rest_route=/batch/v1 at the web application firewall or reverse proxy layer. Cloudflare has deployed WAF rules for customers with the WordPress managed ruleset. This is a mitigation, not a fix — it closes the specific attack path but leaves the underlying CVEs unpatched.

Step 3: Enable a persistent object cache. Sites running Redis or Memcached block the RCE progression even on unpatched versions, degrading the attack from code execution to SQL injection. This is a worthwhile hardening step regardless of wp2shell, but it is not a substitute for patching.

Step 4: Check for indicators of compromise. If your site ran a vulnerable version between July 17 and today, treat it as potentially compromised. Look for: unexpected PHP files in wp-content/uploads/, unfamiliar administrator accounts, modified wp-config.php, unusual cron jobs, and unexpected outbound connections from the web server process. Searchlight Cyber's public checker at wp2shell.com allows site owners to test their own instances against the vulnerability.

Step 5: Review server-level logs. Look for POST requests to /wp-json/batch/v1 or /?rest_route=/batch/v1 from unknown IPs, particularly those returning HTTP 200 responses in the hours and days following July 17.

What This Means for Indian WordPress Operators

For Indian businesses running WordPress — whether for corporate sites, e-commerce, patient portals, or fintech dashboards — wp2shell is a DPDPA-relevant event. A successful exploitation achieves complete server compromise: full access to the WordPress database (which may contain customer personal data, payment records, or health information), credentials for connected services, and the ability to deploy persistent webshells that survive a WordPress update.

Under DPDPA, a personal data breach must be reported to the Data Protection Board in the "prescribed manner," and under CERT-In Directions, it must be reported within 6 hours of detection. A compromise that began on July 17 and is discovered today is already a late-reporting situation. The remediation and incident response clock are running simultaneously.

Alastor Pulse continuous VAPT includes web application and CMS security checks that flag unpatched WordPress core versions and exposed REST API endpoints as part of its ongoing attack surface monitoring. Enforster AI's DAST scanning can enumerate and validate REST API exposure across your web properties, including the batch endpoint. If you run WordPress at scale or on customer-facing applications, contact the Alastor InfoSec team for an emergency assessment and guidance on post-compromise verification.

TL;DR Patch Table

Branch	Vulnerable Versions	Fixed Version	Risk
WordPress 7.x	7.0.0 – 7.0.1	7.0.2	Unauthenticated RCE
WordPress 6.9.x	6.9.0 – 6.9.4	6.9.5	Unauthenticated RCE
WordPress 6.8.x	6.8.0 – 6.8.5	6.8.6	Authenticated SQLi

If your site is on any version in the middle column and has not yet updated, update it before reading the rest of your emails today.

wp2shell is the rarest and most dangerous class of web vulnerability: unauthenticated code execution in a platform with 500 million deployments, triggered by a single HTTP request against a default installation — patch immediately and verify.