Updated July 18, 2026: The vulnerabilities have now received official CVE identifiers. Researchers have also published the complete exploitation process, confirmed an important condition involving persistent object caching, and released a working proof-of-concept (PoC). This article has been updated to reflect those developments.
A newly disclosed vulnerability chain in WordPress core allows remote attackers to execute code without authentication. Because the issue exists in the core platform itself, even a clean WordPress installation with no plugins installed can be vulnerable. All WordPress 6.9 and 7.0 releases were affected until security updates 6.9.5 and 7.0.2 were released on Friday. WordPress also activated what it describes as forced updates through its automatic update system.
The attack, known as wp2shell, combines two separate security flaws rather than relying on a single bug. CVE-2026-63030 identifies a flaw involving confusion within the REST API batch route, while CVE-2026-60137 tracks a SQL injection vulnerability in WordPress core. When combined, these vulnerabilities allow an unauthenticated attacker to progress from a simple HTTP request to full remote code execution.
Since the patches became available, researchers have publicly documented how the exploit works, and a functional proof-of-concept has already been published on GitHub.
The REST API batch-route vulnerability was discovered by Adam Kues of Assetnote, the attack surface management division of Searchlight Cyber. He responsibly reported the issue through WordPress’s HackerOne bug bounty program.
According to the published wp2shell research, the attack requires no special conditions and can be carried out by an anonymous user. The SQL injection vulnerability was independently reported by security researchers TF1T, dtro, and haongo.
Although Searchlight has not yet released its own detailed technical analysis, the company has directed website administrators to a verification tool available at wp2shell.com. At this stage, however, withholding technical documentation offers little additional protection because the security patches are publicly available, allowing other researchers to analyze the code changes themselves.
The two vulnerabilities affect different WordPress release branches, making version numbers critical when determining exposure. The SQL injection issue impacts versions dating back to WordPress 6.8, while the REST API batch-route vulnerability—which enables unauthenticated remote code execution when combined with the SQL injection—was introduced in WordPress 6.9.
The affected versions are divided as follows:
- WordPress 6.8.0 through 6.8.5: Vulnerable only to the SQL injection flaw. Fixed in 6.8.6.
- WordPress 6.9.0 through 6.9.4: Vulnerable to the complete remote code execution chain. Fixed in 6.9.5.
- WordPress 7.0.0 through 7.0.1: Vulnerable to the complete remote code execution chain. Fixed in 7.0.2.
- WordPress 7.1 Beta 2: Includes fixes for both vulnerabilities.
Because the REST API batch-route issue does not exist in the 6.8 branch, WordPress 6.8 installations cannot be exploited for remote code execution through this attack chain. For that reason, version 6.8.6 addresses only the SQL injection vulnerability.
WordPress has not confirmed whether websites that previously disabled automatic updates will still receive the forced security release. Administrators should verify the installed WordPress version instead of assuming the update has already been applied.
Searchlight estimates that WordPress powers more than 500 million websites worldwide. However, that number represents the platform’s overall install base rather than the number of sites exposed to this specific attack. The complete remote code execution chain affects only WordPress 6.9 and later, a release first published on December 2, 2025. As a result, every site vulnerable to code execution is running a version that is less than eight months old, although no official advisory has disclosed how many active websites fall into that category.
How the wp2shell Exploit Chain Works
The complete exploit chain is built on two relatively small implementation flaws that become significantly more dangerous when combined. The SQL injection originates from the WP_Query parameter author__not_in. Under normal conditions, this parameter expects an array, but if an attacker supplies a string instead, the expected array validation is bypassed, allowing the unsanitized value to be inserted directly into the SQL query.
The second vulnerability provides the path needed to reach that parameter without requiring authentication. WordPress’s /wp-json/batch/v1 endpoint is designed to process multiple REST API requests within a single call. Internally, it manages these requests using two parallel arrays. When one sub-request triggers an error, the arrays become misaligned by a single position, causing a later request to be handled by the wrong endpoint.
That request confusion allows attackers to bypass the endpoint’s intended allow-list restrictions. As a result, malicious input reaches the vulnerable WP_Query parameter without requiring a valid login, completing the remote code execution chain. While the batch endpoint itself has existed since WordPress 5.6 in 2020, the logic flaw that makes this attack possible was introduced only in WordPress 6.9.
CVSS Scores Tell a Different Story
The vulnerability ratings deserve careful attention. WordPress classifies the complete remote code execution chain as Critical in its security advisory. However, the corresponding CVE entry assigns it a CVSS score of 7.5, placing it in the High severity category instead.
The scoring reflects the impact of the route confusion primarily as unauthorized data access rather than considering the broader integrity and availability consequences typically associated with remote code execution. By comparison, the SQL injection vulnerability carries a Critical severity with scores exceeding 9.1.
As a result, the issue widely described as the critical remote code execution vulnerability actually receives the lower numerical score of the two. This difference exists because the SQL injection is evaluated based on its direct database impact, while the REST API route confusion is assessed independently as a request-handling flaw. Security teams should therefore monitor both CVE-2026-63030 and CVE-2026-60137 instead of relying solely on their severity labels.
Persistent Object Cache Reduces One Attack Path
Cloudflare has identified an important condition that limits the remote code execution chain. According to the company, successful code execution requires the target WordPress installation not to use a persistent object cache. Cloudflare released managed WAF protections alongside the public disclosure.
Since a standard WordPress installation does not enable persistent object caching by default, default deployments remain exposed to the complete exploit chain.
Websites using Redis or Memcached as a persistent object cache may not be vulnerable to this specific remote code execution path. However, this behavior should not be treated as a security fix, as it does not eliminate the underlying SQL injection vulnerability.
Detection Tools Begin Catching Up
Now that both vulnerabilities have official CVE identifiers, vulnerability management platforms can begin adding detection support. Rapid7 has announced that authenticated checks for InsightVM and Nexpose are scheduled for release on July 20.
At the time of writing, neither vulnerability has been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog because no confirmed cases of active exploitation have been publicly reported as of July 18. Even so, the absence of confirmed attacks should not be interpreted as evidence that exploitation is unlikely, particularly now that technical details and a working proof-of-concept are publicly available.
