WordPress powers a massive portion of the internet, with estimates exceeding 500 million active sites. While many past high-profile issues stemmed from third-party plugins or themes, WP2Shell resides entirely in WordPress Core. This means even clean, out-of-the-box installations running vulnerable versions are at risk.
The Nature of the Vulnerability
WP2Shell is not a single bug but a carefully chained pair of flaws: CVE-2026-63030 and CVE-2026-60137.
CVE-2026-63030 involves a route confusion vulnerability in WordPress’s REST API batch endpoint (/wp-json/batch/v1 or /?rest_route=/batch/v1). Introduced years earlier and refined in version 6.9, the batch feature allows multiple API requests to be processed in a single call. Researchers discovered that an error in one sub-request can desynchronize internal tracking arrays. This mismatch lets an attacker force a subsequent request to execute under an unintended handler, effectively bypassing access controls.
CVE-2026-60137 is a SQL injection vulnerability in the WP_Query class, specifically involving the author__not_in parameter. When a string is supplied instead of the expected array, certain sanitization checks are skipped, allowing raw input to reach the database query.
By combining the two, an anonymous attacker can craft a single malicious batch request that first confuses the routing logic and then injects SQL to escalate privileges—ultimately achieving remote code execution. In many cases, this leads to the creation of an administrator account or the direct placement of webshells.
Importantly, the full RCE chain applies to WordPress versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. The SQL injection alone also affects earlier 6.8.x releases (through 6.8.5). Sites running versions prior to 6.9 are not vulnerable to the complete pre-auth RCE via this specific chain, though the SQL injection still poses a serious risk.
One mitigating factor exists: the code-execution path is less reliable on sites using a persistent object cache such as Redis or Memcached. Default installations, however, do not use such caching and remain fully exposed.
Discovery and Disclosure
The primary discovery of the batch-route confusion was credited to Adam Kues of Searchlight Cyber (Assetnote), who reportedly leveraged advanced AI assistance during research. The SQL injection component was independently reported by other researchers. Searchlight responsibly disclosed the issues through WordPress’s HackerOne program, allowing time for patches before public details emerged.
WordPress responded swiftly. On July 17, 2026, the project released versions 6.9.5 and 7.0.2 containing the necessary fixes. A 6.8.6 update addressed the SQL injection for the older branch. WordPress also activated forced update mechanisms for many auto-updating sites, underscoring the severity.
Despite the coordinated disclosure, technical details and proof-of-concept code appeared online within hours of the patches. Security firms and independent researchers reverse-engineered the changes, confirming the exploit chain and releasing public tools. A checker site, wp2shell.com, was made available by the discoverers to help administrators test their installations without risking exploitation.
Exploitation in the Wild
The speed of real-world abuse has been alarming. Within days of disclosure, multiple cybersecurity firms—including Wiz Research—confirmed active exploitation. Attackers began scanning for vulnerable batch endpoints and deploying persistent backdoors.
Observed post-exploitation activity includes:
- Uploading malicious plugins that function as full-featured webshells
- Enumerating administrator accounts via the REST API
- Attempting local file inclusion to steal configuration secrets
- Establishing authenticated sessions for further compromise
Some payloads are simple one-liner PHP webshells designed for stealth. Others are sophisticated, obfuscated plugins offering file management, database access, and privilege escalation modules. High-volume scanning has also been detected, indicating both opportunistic bots and more targeted campaigns.
Because the attack requires only a single unauthenticated HTTP request, automated tools can rapidly compromise large numbers of sites. Organizations running self-hosted WordPress instances in cloud environments have been particularly visible targets.
Impact and Risk Assessment
The potential blast radius is enormous. Any site running a vulnerable 6.9 or 7.0 release without mitigations is at immediate risk of full takeover. Once an attacker gains code execution, they can steal data, deface the site, inject malware, use the server for further attacks, or pivot into internal networks.
WordPress’s own advisory rated the RCE chain as Critical. While individual CVE scores vary (one focusing more on the injection’s database impact), the practical severity of unauthenticated remote code execution on default configurations is unambiguous.
Particularly concerning is the fact that many site owners still lag in applying core updates, relying instead on plugin security or hosting provider protections. Shared hosting environments and sites managed by less technical users face elevated risk.
Mitigation and Remediation
The primary and strongest recommendation is immediate updating:
- Upgrade to WordPress 7.0.2 (or later)
- Or, for the 6.9 branch, upgrade to 6.9.5
- Sites on 6.8 should move to 6.8.6 to close the SQL injection
WordPress’s auto-update system has already pushed these releases to many sites, but administrators should verify their current version rather than assume success—especially if auto-updates were previously disabled.
For environments where immediate updating is not feasible, temporary mitigations focus on restricting the batch endpoint:
- Block /wp-json/batch/v1 and ?rest_route=/batch/v1 at the web application firewall (WAF) level
- Install a plugin that disables unauthenticated REST API access
- Deploy a small custom plugin that rejects anonymous requests to the batch route
These measures can break legitimate integrations that rely on the batch API and should be treated strictly as short-term stopgaps.
Additional defensive steps include monitoring for unusual traffic to the batch endpoints (particularly responses with HTTP 207 Multi-Status), reviewing recently installed plugins, checking for unexpected administrator accounts, and scanning for known webshell signatures.
Hosting providers and managed WordPress platforms have largely applied protections at the infrastructure level, but self-hosted and VPS users bear full responsibility for their own defenses.
Broader Lessons
WP2Shell highlights several ongoing challenges in the WordPress ecosystem. Core vulnerabilities of this severity remain rare, yet their impact is magnified by WordPress’s enormous market share. The rapid transition from disclosure to public exploits and active attacks demonstrates how modern vulnerability research and automation compress traditional response windows.
It also underscores the value of defense-in-depth: keeping core software updated, limiting unnecessary API exposure, employing WAFs, and maintaining robust monitoring. Sites that treat security as a continuous process rather than a one-time configuration fare far better when critical flaws emerge.
As of late July 2026, patch adoption continues to rise, and exploitation attempts remain active. Site owners who have not yet updated should treat this as an urgent priority. In the high-stakes environment of modern web security, hesitation can be costly. WP2Shell serves as a stark reminder that even the most widely used platforms require constant vigilance.
