WordPress Core Vulnerabilities Unlocked by Anonymous HTTP Request Leading to Remote Code Execution

An anonymous HTTP request can execute code on a WordPress site due to a critical flaw within the core software. This vulnerability, affecting all WordPress versions 6.9 and 7.0, remained unpatched until the recent release of versions 6.9.5 and 7.0.2, which also activated WordPress’s forced update mechanism. The exploitation relies on chaining two distinct security weaknesses, now officially recognized with CVE IDs: CVE-2026-63030, a REST API batch-route confusion, and CVE-2026-60137, a SQL injection flaw within WordPress core. Together, these vulnerabilities enable an unauthenticated attacker to achieve arbitrary code execution on a vulnerable WordPress installation. The full exploitation mechanism has been publicly disclosed, and a working proof-of-concept is now available, significantly increasing the immediate threat to websites running outdated versions.

Unveiling the wp2shell Vulnerability Chain

The discovery of the "wp2shell" vulnerability chain has sent ripples of concern through the vast WordPress ecosystem. This sophisticated exploit is not a single bug but a combination of two distinct security flaws that, when chained together, grant attackers a pathway to full control over a vulnerable website. The first component, CVE-2026-63030, identified by Adam Kues at Assetnote, a division of Searchlight Cyber, involves a critical misconfiguration within the WordPress REST API’s batch route functionality. This flaw allows for a confusion in how multiple requests are processed, effectively bypassing intended security checks.

The second crucial element, CVE-2026-60137, is a SQL injection vulnerability rooted deeply within the WordPress core. This type of vulnerability allows attackers to manipulate database queries, potentially leading to unauthorized data access or modification. The SQL injection itself was reported independently by multiple security researchers, including TF1T, dtro, and haongo, highlighting the pervasive nature of such coding errors.

When combined, these two vulnerabilities create a potent attack vector. An anonymous HTTP request can initiate the sequence, leveraging the REST API batch-route confusion to bypass authentication. This initial bypass then allows the attacker to target the vulnerable SQL query. The consequence is the ability to execute arbitrary code on the server, effectively giving the attacker complete command over the compromised WordPress site. The implications are severe, ranging from website defacement and data theft to the installation of malware and the use of the compromised site for further malicious activities.

Chronology of Disclosure and Patching

The timeline of the wp2shell vulnerability and its subsequent patching is crucial for understanding the evolving threat landscape.

• Initial Discovery of Batch-Route Bug: Adam Kues at Assetnote discovered the REST API batch-route confusion (CVE-2026-63030) and responsibly reported it through WordPress’s HackerOne program.
• Discovery of SQL Injection: Concurrently, security researchers TF1T, dtro, and haongo independently identified the SQL injection vulnerability (CVE-2026-60137) within WordPress core.
• Chaining the Vulnerabilities: Security researchers, including those at Searchlight Cyber, successfully demonstrated how these two vulnerabilities could be chained together to achieve unauthenticated remote code execution (RCE). This combined exploit was subsequently dubbed "wp2shell."
• Public Disclosure of Mechanism: Following the patching process, the full technical details of the wp2shell exploit, including a working proof-of-concept, were published. This move significantly raised the stakes, providing potential attackers with a direct roadmap to exploit vulnerable systems.
• WordPress Releases Patched Versions: WordPress addressed the vulnerabilities by releasing patched versions of its core software: WordPress 6.9.5 and WordPress 7.0.2. These updates were critical in mitigating the immediate threat.
• Forced Updates Activated: Notably, WordPress also enabled its "forced updates" mechanism for these releases. This ensures that sites with auto-updates enabled will receive the patch automatically, regardless of user settings, thereby accelerating the deployment of the fix across the user base.
• Analysis and Broader Context: Security firms and researchers began publishing detailed analyses of the vulnerabilities, their impact, and the conditions under which they could be exploited. This included information about specific version ranges affected and potential workarounds.
• CVE IDs Assigned: The two core vulnerabilities were formally assigned CVE IDs, CVE-2026-63030 and CVE-2026-60137, allowing for standardized tracking and vulnerability management.
• Proof-of-Concept Publicly Available: The availability of a working proof-of-concept on platforms like GitHub provided a clear demonstration of the exploit’s capabilities and further incentivized rapid patching.

This chronology underscores the race against time between the disclosure of a severe vulnerability and the widespread deployment of its fix.

Technical Deep Dive: The Mechanics of Exploitation

The wp2shell vulnerability chain hinges on two distinct technical flaws that, when exploited in tandem, bypass authentication and achieve remote code execution.

CVE-2026-60137: The SQL Injection at its Core

The SQL injection vulnerability resides within the WP_Query class, a fundamental component of WordPress responsible for querying the database. Specifically, the flaw is triggered when the author__not_in parameter is manipulated. In a typical scenario, this parameter expects an array of author IDs to exclude from a query. However, if an attacker provides a string value instead of an array, the internal validation checks designed to handle array inputs are bypassed. This allows the raw, attacker-controlled string to be directly incorporated into the SQL query. The consequence of this direct injection is the ability to manipulate database operations, potentially leading to data leakage, unauthorized modifications, or even the execution of arbitrary SQL commands, depending on the database’s configuration and privileges.

CVE-2026-63030: The REST API Batch-Route Confusion

The second crucial piece of the puzzle, CVE-2026-63030, lies within the WordPress REST API’s batch endpoint (/wp-json/batch/v1). This endpoint is designed to allow multiple individual REST API requests to be bundled into a single HTTP request, improving efficiency for certain operations. The batch endpoint manages these bundled requests by tracking them using two parallel arrays. However, a subtle bug exists in how errors are handled within these sub-requests.

When an error occurs in one of the sub-requests, it can cause these two parallel arrays to become misaligned by one position. This misalignment is critical because it means that subsequent requests within the same batch can be processed by an incorrect handler. In the context of the wp2shell exploit, this confusion allows an attacker to craft a batch request where the malformed author__not_in parameter, intended for the SQL injection, is inadvertently processed by a handler that would normally expect and sanitize such input if it were part of a legitimate, authenticated request. This bypasses the intended security boundary, effectively landing the attacker’s malicious input directly into the vulnerable WP_Query parameter without any need for authentication.

The batch endpoint itself has been part of WordPress core since version 5.6, introduced in November 2020. However, the specific confusion that abuses it for this exploit is a newer flaw, present only in WordPress version 6.9. This means that the combination of vulnerabilities requires a relatively recent version of WordPress to be exploitable for RCE.

Versioning and Exposure: A Nuanced Picture

The extent of exposure to the wp2shell vulnerability is not uniform across all WordPress versions, with different versions being vulnerable to different components of the exploit. This distinction is crucial for understanding the precise threat landscape.

• SQL Injection (CVE-2026-60137): This vulnerability has a deeper historical reach, affecting WordPress versions as far back as 6.8. This means that any site running WordPress 6.8 or any subsequent version prior to the patched releases, without the SQL injection fix, is susceptible to this particular flaw.
• REST API Batch-Route Confusion (CVE-2026-63030): The vulnerability that enables unauthenticated remote code execution by chaining the SQL injection is more recent. This confusion in the batch route is present only in WordPress versions starting from 6.9. Therefore, sites running versions 6.8 are not vulnerable to the full RCE chain, as they lack the batch-route confusion component. However, they remain vulnerable to the underlying SQL injection.

This versioning difference leads to a segmented exposure:

• WordPress 6.8.x: Vulnerable to the SQL injection (CVE-2026-60137) but not the full RCE chain. The patched version for this line is 6.8.6, which specifically addresses the SQL injection.
• WordPress 6.9.x: Vulnerable to both the SQL injection (CVE-2026-60137) and the REST API batch-route confusion (CVE-2026-63030), making them susceptible to the full unauthenticated RCE chain. The patched version for this line is 6.9.5.
• WordPress 7.0.x: Similarly vulnerable to both components prior to the patch. The patched version is 7.0.2.

The patched version, 7.1 beta2, incorporates fixes for both vulnerabilities, effectively closing the door on the wp2shell exploit chain.

The Impact of Forced Updates and Persistent Object Caching

WordPress’s decision to implement forced updates for versions 6.9.5 and 7.0.2 is a significant factor in mitigating the immediate threat posed by wp2shell. This mechanism aims to ensure that a large number of websites are patched quickly, especially those where administrators might not actively monitor or apply updates promptly. However, the effectiveness of this forced push on sites that have explicitly disabled auto-updates remains a point of concern. Website owners are strongly advised to verify their current WordPress version rather than assuming the update has been applied.

An additional factor influencing the exploit’s blast radius is the presence of a persistent object cache. According to analysis from Cloudflare, which has released Web Application Firewall (WAF) rules to protect against this vulnerability, the code execution path of the exploit only functions when a site is not running a persistent object cache. Default WordPress installations typically do not have such caches configured, meaning they are directly exposed.

However, websites that utilize persistent object caches like Redis or Memcached might be shielded from the RCE component of this specific exploit chain. It is crucial to understand that this is a side effect of the caching mechanism and not a direct security fix. Furthermore, the presence of a persistent object cache does not mitigate the underlying SQL injection vulnerability (CVE-2026-60137), which can still be exploited independently to compromise data. Therefore, even sites with object caching in place are not entirely immune and still require patching.

Broader Implications and Industry Reactions

The wp2shell vulnerability has ignited significant discussion and concern within the cybersecurity community and the broader web development industry, primarily due to the sheer scale of WordPress’s user base. WordPress powers an estimated 43% of all websites on the internet, translating to hundreds of millions of potential targets.

Searchlight Cyber’s Role: Searchlight Cyber, through its attack surface management arm Assetnote, played a pivotal role in uncovering and reporting the batch-route confusion. Their decision to hold back their full technical write-up initially, while providing a checker at wp2shell.com, allowed for a controlled disclosure. However, the open-source nature of WordPress meant that once the patch was released, other researchers could quickly dissect it, publish the mechanism, and create proof-of-concept exploits, as indeed happened.

Official Responses and Advisories: WordPress’s own security advisory rates the RCE chain as "Critical." However, the official CVE record assigns a CVSS score of 7.5, categorizing it as "High." This discrepancy is notable, as the scoring metrics primarily credit data access and do not fully account for the integrity and availability losses typically associated with successful code execution. The SQL injection, by itself, warrants a score higher than 9.1, also "Critical." This highlights the importance of tracking both CVEs individually, rather than solely relying on the "Critical RCE" label, as the injection’s direct database impact is severe on its own.

Vulnerability Scanners and Threat Intelligence: With CVE IDs now assigned, vulnerability scanning solutions are rapidly incorporating detection for wp2shell. Rapid7, for instance, announced that authenticated checks for InsightVM and Nexpose would be available by July 20th. As of July 18th, the vulnerability was not yet listed on CISA’s Known Exploited Vulnerabilities (KEV) catalog, which requires confirmed exploitation in the wild. No widespread exploitation had been reported at that time, offering a thin layer of comfort. However, the rapid public availability of a proof-of-concept exploit means this situation could change swiftly.

Historical Context and Mass Exploitation: The WordPress ecosystem has become a prime target for large-scale exploitation. The article references past incidents, such as a flaw in a caching plugin that, despite being public and patched, was used by the "WP-SHELLSTORM" crew to compromise over 17,000 sites. This vulnerability, which worked on a non-default setting, underscores a recurring pattern: even patched vulnerabilities, especially those with public exploits and impacting widely used platforms, can lead to massive compromises. The wp2shell vulnerability, being public, patched, and working on default settings for many installations, presents a similar, if not heightened, risk.

Mitigating the Threat: Immediate Actions for Website Owners

For website owners unable to update their WordPress core immediately, several temporary mitigation strategies can be employed. These are stopgap measures designed to block anonymous access to the vulnerable batch endpoint and should not be considered permanent solutions.

• Web Application Firewall (WAF) Configuration: Implementing WAF rules can help block malicious requests targeting the /wp-json/batch/v1 endpoint. This is a proactive measure that can prevent attackers from even reaching the vulnerable code. Cloudflare has notably released specific WAF rules for this purpose.
• Endpoint Blocking: It is possible to block access to the batch endpoint at the web server level (e.g., via .htaccess for Apache or nginx.conf for Nginx). This would prevent any requests from reaching the WordPress application, thus nullifying the exploit. However, this approach carries a risk of breaking legitimate functionalities that rely on the batch endpoint, potentially impacting plugin or theme operations.
• Access Control Lists (ACLs): Network-level ACLs can be configured to restrict access to the batch endpoint to only trusted IP addresses. This is a more granular approach but requires careful management to avoid inadvertently blocking legitimate users or services.

It is imperative to understand that these are temporary measures. The only definitive solution is to update WordPress core to the patched versions (6.9.5, 7.0.2, or later). The open-source nature of WordPress means that its codebase is publicly available. While this fosters transparency and community contribution, it also means that once a patch is released, its internal workings can be quickly analyzed by malicious actors. WordPress’s aggressive forced update strategy for these critical patches reflects an acknowledgment of this reality, aiming to outpace the exploitation of the vulnerability before it becomes even more widespread.

The race is now on between the automated patching of millions of websites and the potential exploitation of those that remain vulnerable. Monitoring website traffic for suspicious activity targeting the batch endpoint, alongside ensuring timely updates, will be crucial in determining the ultimate impact of the wp2shell vulnerability.