A chained vulnerability dubbed wp2shell was publicly detailed on July 18, 2026, comprising two separate flaws in WordPress core that together allow an anonymous HTTP request to execute arbitrary code on any affected WordPress installation. CVE-2026-63030 is a REST API batch-route confusion vulnerability. CVE-2026-60137 is a SQL injection in WordPress core. Chained, they take an unauthenticated HTTP request all the way to remote code execution. No plugins are required. A bare WordPress installation with default settings is fully exploitable. WordPress shipped emergency patches in versions 6.9.5 and 7.0.2 on July 18 and enabled forced auto-updates through its auto-update system. A working proof-of-concept exploit was publicly released the same day the CVE IDs were assigned, compressing the window between disclosure and exploitation to hours. WordPress powers approximately 43 percent of all websites globally, per W3Techs CMS market share data. The practical scope of this vulnerability is measured in millions of sites.

Figure 1: wp2shell exposure scope. WordPress powers 43% of all websites globally. The combination of affected version penetration and incomplete auto-update adoption leaves a large window of unpatched exposure in the first 48 hours.

Facts

Field	Detail
Vulnerability Name	wp2shell (researcher-named; two CVEs comprising the chain)
CVE IDs	CVE-2026-63030 (REST API batch-route confusion); CVE-2026-60137 (SQL injection in WordPress core)
Attack Type	Chained: unauthenticated REST API confusion → SQL injection → remote code execution
Authentication Required	None. An anonymous HTTP request is sufficient to trigger the full chain.
Affected Versions	WordPress 6.9 and 7.0 (all minor versions before 6.9.5 and 7.0.2)
Plugins Required	No. A stock WordPress installation with zero plugins is exploitable.
Patches Available	Yes. WordPress 6.9.5 and 7.0.2 released July 18, 2026. Auto-update enabled via WordPress forced update system.
Public Exploit	Yes. Working proof-of-concept published July 18, 2026, the same day CVE IDs were assigned.
Additional complication	A persistent object cache condition surfaced on July 18, affecting patched sites running specific caching configurations. Details published by The Hacker News.

Table 1: wp2shell Fast Facts.

How the Attack Works

wp2shell is two bugs, not one, and the chain matters. CVE-2026-63030 exploits a confusion in how WordPress’s REST API handles batch route processing. By crafting an HTTP request that routes through the batch endpoint in an unexpected way, an attacker can bypass the authentication checks that would normally gate access to sensitive operations. Alone, this provides limited access.

CVE-2026-60137 is a SQL injection vulnerability directly in WordPress core, not in a plugin or theme. SQL injection in the core means there is no workaround involving plugin removal or theme switching. Any site running an affected version carries the flaw regardless of configuration.

Chained in sequence, CVE-2026-63030 bypasses authentication checks, and CVE-2026-60137 provides the mechanism to inject and execute arbitrary database commands that escalate to code execution on the server. The full chain operates on a single anonymous HTTP request. There is no brute force, no credential requirement, and no interaction from an authenticated user needed.

Since the full mechanism was published on July 18 alongside CVE assignment, attackers have a complete technical roadmap. The publicly released proof-of-concept demonstrates the chain works against stock WordPress installations. The typical time between proof-of-concept publication and active mass exploitation campaigns in the WordPress ecosystem has historically been measured in hours to days, not weeks.

The Persistent Object Cache Complication

A further technical wrinkle emerged on July 18: a persistent object cache condition that surfaces on patched sites running specific caching configurations. The Hacker News reported that sites running WordPress 6.9.5 or 7.0.2 with a persistent object cache, particularly sites using Redis or Memcached as a caching backend, may carry a residual condition from the SQL injection component even after patching. The precise nature of this condition and its exploitability post-patch is still being assessed at time of writing. Sites running persistent object caching should flush their cache immediately after applying the patch and verify integrity of their WordPress database tables.

Why the Scope Is Unusually Large

Most WordPress vulnerabilities affect a specific plugin or theme, limiting exposure to sites that have installed that component. wp2shell is in WordPress core itself, which means it applies equally to every site running an affected version regardless of what plugins or themes are installed, what hosting provider is used, or what security plugins are in place at the application layer.

WordPress’s market share of 43 percent of all websites globally means wp2shell is a vulnerability measured in tens of millions of potential targets at the moment of disclosure. WordPress’s auto-update system, which was enabled for forced updates on 6.9.5 and 7.0.2, will reduce that number significantly, but auto-update coverage is not universal. Sites where auto-updates have been disabled, sites on managed hosting environments that review updates before applying them, and sites with custom WordPress configurations that disable the update mechanism will require manual intervention.

Immediate Actions

• Verify WordPress version immediately. Any site running 6.9.x or 7.0.x below 6.9.5 or 7.0.2 respectively is vulnerable. Log into the WordPress admin dashboard and check Dashboard, then Updates.
• Apply the patch manually if auto-update has not already triggered. Navigate to Dashboard, then Updates in the WordPress admin and apply version 6.9.5 or 7.0.2. If the site does not show the update, verify that the auto-update system is functional and not blocked by a plugin or hosting configuration.
• Flush persistent object caches immediately after patching. Sites running Redis, Memcached, or other persistent object caching should flush all cached objects and verify database table integrity following the patch application.
• Review server logs for anomalous REST API batch endpoint requests in the period between July 18 and the time of patching. Unusual POST requests to /wp-json/batch/v1 or equivalent routes prior to patching may indicate exploitation attempts.
• Check for indicators of compromise including unexpected administrator accounts, unfamiliar PHP files in the WordPress upload directory, modified core files, and unusual outbound connections from the web server.
• For WordPress hosting providers and managed WordPress platforms: treat all customer sites on affected versions as compromised until patched and verified, and prioritise mass auto-update deployment over review cycles given the public proof-of-concept availability.