Critical Remote Code Execution Vulnerability Discovered in WordPress Core, Affecting Hundreds of Millions of Websites

An unprecedented security flaw, designated "wp2shell," has been identified within the core architecture of WordPress, enabling unauthenticated attackers to execute arbitrary code on vulnerable websites. This critical remote code execution (RCE) vulnerability, stemming from a sophisticated chain of two distinct bugs, has put a significant portion of the internet at risk, prompting rapid emergency patches and forced updates by the WordPress project. The exploit chain affects all WordPress sites running versions 6.9 and 7.0 until Friday, July 18, 2026, when crucial updates (6.9.5 and 7.0.2) were pushed out.

The Discovery and Immediate Response

The initial discovery of a key component of this vulnerability, specifically the REST API batch-route confusion, was made by Adam Kues of Assetnote, the attack surface management division of Searchlight Cyber. Kues responsibly reported his findings through WordPress’s official HackerOne bug bounty program, a standard practice for disclosing critical security flaws. Concurrently, a separate but equally vital SQL injection vulnerability within WordPress core was independently reported by researchers TF1T, dtro, and haongo. These two distinct flaws, initially thought to be separate, were later found to be chainable, leading to the devastating RCE capability.

Following the internal disclosure and validation of these vulnerabilities, the WordPress security team moved swiftly. On Friday, July 18, 2026, WordPress released urgent updates – versions 6.9.5 and 7.0.2 – to address the issues. Crucially, these updates were pushed through WordPress’s auto-update system, leveraging what the project calls "forced updates" to ensure rapid deployment across its vast ecosystem. This proactive measure underscored the severe nature of the threat.

Unpacking the ‘wp2shell’ Exploit Chain

The "wp2shell" designation encapsulates the two vulnerabilities that, when chained together, achieve pre-authentication RCE. These are:

1. CVE-2026-63030: The REST API Batch-Route Confusion. This bug resides in the /wp-json/batch/v1 route, a feature introduced in WordPress 5.6 (2020) to allow multiple sub-requests to be processed in a single API call. The core of the confusion lies in how WordPress tracks these sub-requests. An error in processing one sub-request can cause the internal arrays tracking these requests to fall out of sync by one position. This desynchronization means that an attacker’s input intended for one request handler can inadvertently be routed to a different, more permissive handler, bypassing security checks and landing malicious data where it shouldn’t. This specific confusion mechanism is new to WordPress 6.9 and subsequent versions.

2. CVE-2026-60137: SQL Injection in WordPress Core. This SQL injection vulnerability is found within the WP_Query‘s author__not_in parameter. Normally, this parameter expects an array of author IDs. However, the flaw allows an attacker to supply a string instead of an array. When a string is provided, a critical type-checking mechanism is bypassed, leading to the raw, unsanitized value being directly inserted into the SQL query. This gives an attacker the ability to manipulate the database query, potentially extracting sensitive information or altering data. This particular SQL injection has a broader reach, extending back to WordPress version 6.8.

   

The true danger of "wp2shell" emerges when these two vulnerabilities are combined. The REST API batch-route confusion (CVE-2026-63030) provides an unauthenticated pathway to reach the vulnerable author__not_in parameter, which would typically require authentication. By leveraging the batch endpoint’s desynchronization, an anonymous request can bypass the allow-list and inject malicious input into the WP_Query parameter. This chained exploitation allows an anonymous user to achieve arbitrary code execution, effectively taking full control of the affected WordPress site.

Chronology of a Critical Disclosure

• December 2, 2025: WordPress 6.9 is released, introducing the batch-route confusion component of the vulnerability.
• Early July 2026: Adam Kues of Assetnote discovers and reports the batch-route confusion (CVE-2026-63030) via HackerOne. Independently, TF1T, dtro, and haongo report the SQL injection (CVE-2026-60137).
• Pre-July 18, 2026: WordPress security team works on patches for both vulnerabilities.
• July 18, 2026 (Friday): WordPress releases emergency updates: 6.9.5 and 7.0.2, including "forced updates" via its auto-update system. WordPress 7.1 beta2 also receives both fixes.
• Post-July 18, 2026:
  • Searchlight Cyber publishes a high-level write-up under the name "wp2shell," detailing the pre-authentication RCE and pointing site owners to a checker at wp2shell.com. They initially hold back full technical details.
  • Despite Searchlight’s initial reticence, other security researchers, analyzing the released patches, quickly reverse-engineer the full mechanism of the exploit chain.
  • A working proof-of-concept (PoC) exploit is made public on GitHub, significantly increasing the immediate threat level for unpatched sites.
  • Cloudflare announces the deployment of Web Application Firewall (WAF) rules to protect its users and notes a condition where persistent object caches might inadvertently mitigate the RCE path.
  • Rapid7 confirms that authenticated checks for its InsightVM and Nexpose vulnerability scanners will be available by July 20.

Affected Versions and Patching Landscape

The two components of the "wp2shell" chain affect different WordPress versions, leading to a nuanced exposure profile:

• WordPress 6.9 and 7.0: These versions are fully exposed to the complete RCE chain, as they contain both the SQL injection (CVE-2026-60137) and the batch-route confusion (CVE-2026-63030). Sites running these versions must update to 6.9.5 or 7.0.2 immediately.
• WordPress 6.8: This version is vulnerable to the SQL injection (CVE-2026-60137) but not the batch-route confusion, as that specific flaw was introduced in 6.9. Therefore, 6.8 sites are not exploitable for RCE through this particular chain. WordPress 6.8.6 was released to patch the SQL injection alone.
• WordPress 7.1 beta2: This development version already includes fixes for both vulnerabilities, demonstrating the forward-looking approach to security.

A crucial aspect of the WordPress response was the activation of "forced updates." While this mechanism is designed to rapidly deploy critical security patches, it remains unclear whether it overrides user-configured settings that disable auto-updates. Site administrators are strongly advised to verify their current WordPress version manually rather than assuming the patch has been applied automatically. Given that WordPress powers over 43% of all websites on the internet, with an install base exceeding 500 million, the scale of potential exposure is immense. While the RCE chain specifically targets versions 6.9 and newer (less than eight months old), the total number of websites running these vulnerable versions is substantial.

Discrepancies in Severity Scoring

The severity of "wp2shell" has been subject to varying assessments, which can be confusing for administrators. WordPress’s official advisory on GitHub (GHSA-ff9f-jf42-662q) rates the entire RCE chain as "Critical." However, the corresponding CVE record for the RCE chain scores it at 7.5, classifying it as "High" severity, not "Critical." This discrepancy arises because the CVE scoring for the RCE path primarily credits "data access" as the main impact, rather than the more severe "integrity" or "availability" losses typically associated with arbitrary code execution.

Conversely, the SQL injection (CVE-2026-60137) on its own carries a CVSS score higher than 9.1, classifying it as "Critical." This is because a direct SQL injection has a clear and immediate impact on database integrity and confidentiality. The lesson here for administrators is to track both CVEs and understand the underlying mechanisms rather than relying solely on a single label, as the cumulative effect of these chained vulnerabilities is undeniably critical.

Mitigation and Defensive Strategies

While immediate patching is the definitive solution, several temporary mitigations were suggested for sites unable to update instantly. Searchlight Cyber’s recommendations primarily focus on blocking anonymous access to the batch endpoint (/wp-json/batch/v1). These stopgap measures include:

• Web Application Firewall (WAF) Rules: Deploying WAF rules to block requests to the /wp-json/batch/v1 endpoint for unauthenticated users. Cloudflare, for instance, swiftly rolled out WAF rules for its users.
• Server-Level Blocks: Configuring web servers (e.g., Nginx, Apache) to deny access to the batch endpoint for anonymous requests.
• WordPress Code Snippets: Adding custom code to WordPress to disable or restrict access to the batch API.

It is crucial to understand that these mitigations are temporary and carry caveats. Blocking the batch endpoint can disrupt legitimate integrations or plugins that rely on this functionality. Therefore, they should only be implemented as a short-term measure until the official patches can be applied.

A notable observation, highlighted by Cloudflare, is that the RCE path of "wp2shell" is only effective when a WordPress site is not running a persistent object cache. Default WordPress installations typically do not use a persistent object cache, meaning they are fully exposed. However, sites that front WordPress with solutions like Redis or Memcached as a persistent object cache might inadvertently be off this specific RCE path. This is a side effect of how the exploit interacts with caching mechanisms, not a deliberate fix, and it does not protect against the underlying SQL injection vulnerability.

Broader Implications and Industry Vigilance

The rapid public release of a working proof-of-concept exploit shortly after the patches underscores the inherent "race" between security researchers, developers, and malicious actors. In the open-source world, shipping a fix inevitably provides a "map to the bug," as others can reverse-engineer the changes to understand the vulnerability. WordPress pulled the lever hard on Friday, pushing out updates as fast as possible, but the window for exploitation remains.

The scale of WordPress’s deployment means that vulnerabilities like "wp2shell" have far-reaching implications. Mass exploitation of WordPress sites has become a sophisticated industry. Prior incidents, such as the "WP-SHELLSTORM" campaign, demonstrated how easily thousands of sites could be compromised through a single flaw, even if it was already patched and required non-default settings. "wp2shell" is arguably more dangerous: it’s public, patched, but crucially, it works on default settings, making a vast number of sites immediately vulnerable if not updated.

Security vendors are quickly adapting. Rapid7 announced that authenticated checks for its InsightVM and Nexpose products would be available by July 20, allowing organizations to scan their assets for the vulnerability. As of July 18, the vulnerability was not yet listed on CISA’s Known Exploited Vulnerabilities (KEV) Catalog, which only includes flaws with confirmed in-the-wild exploitation. However, this comfort is thin, as the public PoC significantly increases the likelihood of imminent exploitation.

The coming days and weeks will reveal the true impact of "wp2shell." WordPress’s version statistics will eventually show the uptake rate of the patches, while monitoring network traffic against the /wp-json/batch/v1 endpoint will indicate the intensity of attacker interest. The steeper of these two curves – patch adoption versus exploitation attempts – will ultimately determine how this critical vulnerability is remembered in the annals of web security. For now, the imperative for all WordPress administrators is clear: update immediately, verify the patch, and remain vigilant against potential threats.