WordPress Core Critical Vulnerability, ‘wp2shell,’ Exposes Millions of Sites to Unauthenticated Remote Code Execution.

A newly disclosed critical vulnerability, dubbed ‘wp2shell,’ has sent shockwaves through the WordPress ecosystem, revealing a path for anonymous HTTP requests to execute arbitrary code on unpatched websites. This severe flaw resides deep within the WordPress core, meaning even a bare installation with no plugins is immediately exploitable. The vulnerability primarily impacts WordPress versions 6.9 and 7.0, which were exposed to the threat until Friday, July 17, 2026, when WordPress rapidly deployed patches (6.9.5 and 7.0.2) and initiated a "forced update" mechanism through its auto-update system to mitigate the widespread danger. The full technical mechanism of the attack has since been published, and a working proof-of-concept (PoC) is now publicly available on GitHub, escalating the urgency for web administrators to secure their installations.

The Dual Threat: CVE-2026-63030 and CVE-2026-60137

The ‘wp2shell’ vulnerability is not a singular flaw but rather a sophisticated chain of two distinct bugs, each now assigned its own Common Vulnerabilities and Exposures (CVE) identifier. The first, CVE-2026-63030, is a REST API batch-route confusion vulnerability. The second, CVE-2026-60137, is a SQL injection flaw residing in the WordPress core. When these two vulnerabilities are chained together, they enable an attacker to achieve unauthenticated remote code execution (RCE) with just an anonymous request, bypassing standard security measures and gaining control over the affected WordPress site.

The initial discovery of the batch-route confusion bug was made by Adam Kues, a security researcher at Assetnote, the attack surface management division of Searchlight Cyber. Kues responsibly reported his findings through WordPress’s official HackerOne bug bounty program. Concurrently, the SQL injection vulnerability was independently reported by a group of researchers identified as TF1T, dtro, and haongo, highlighting the critical nature and independent discovery of these severe flaws. Searchlight Cyber later published a detailed write-up under the moniker ‘wp2shell,’ asserting that the attack has "no preconditions and can be exploited by an anonymous user," underscoring the broad applicability and ease of exploitation.

Anatomy of the Attack Chain: How ‘wp2shell’ Works

To understand the severity of ‘wp2shell,’ it’s crucial to delve into the technical intricacies of how these two vulnerabilities interact to form a critical RCE chain.

The first component, the REST API batch-route confusion (CVE-2026-63030), exploits a flaw in WordPress’s /wp-json/batch/v1 endpoint. This endpoint, introduced in WordPress 5.6 in 2020, is designed to enhance efficiency by allowing clients to send multiple REST API sub-requests within a single HTTP call. WordPress processes these sub-requests and tracks them in parallel arrays. The critical flaw arises when an error occurs in one of these sub-requests. This error can cause a desynchronization or an "off-by-one" error between the two parallel arrays, leading to a scenario where a subsequent sub-request is mistakenly processed by the handler intended for a different, earlier request. This confusion allows an attacker to bypass the endpoint’s internal allow-list, effectively routing malicious input to an unintended and vulnerable handler without proper authentication or validation. While the batch endpoint itself has been present for years, this specific confusion vulnerability is a new introduction in WordPress 6.9.

The second, equally critical component is the SQL injection vulnerability (CVE-2026-60137). This flaw is found within the WP_Query class, specifically affecting the author__not_in parameter. WP_Query is a fundamental part of WordPress, used for fetching posts and other content from the database. The author__not_in parameter is intended to exclude posts by specific authors, typically expecting an array of author IDs. The vulnerability manifests when an attacker provides a string instead of an array to this parameter. Due to an insufficient validation check, the system skips the expected array validation and directly incorporates the raw, unvalidated string value into the SQL query. This allows an attacker to inject arbitrary SQL commands into the database query, potentially leading to data exfiltration, modification, or even complete database compromise. This SQL injection vulnerability has a longer history, tracing back to WordPress version 6.8.

The chaining of these two vulnerabilities is what elevates ‘wp2shell’ to an RCE. The batch-route confusion allows an anonymous attacker to inject arbitrary data into parameters that would normally be protected or require authentication, effectively delivering their malicious payload to the SQL injection point. Once the SQL injection is triggered with the attacker-controlled input, it can be crafted to execute arbitrary code on the underlying server, granting full control over the WordPress installation. This seamless transition from an unauthenticated request to complete system compromise highlights the critical nature of this attack vector.

Chronology of Disclosure and Rapid Response

The timeline of the ‘wp2shell’ vulnerability underscores the rapid pace of modern cybersecurity threats and the pressures on open-source projects to respond decisively.

• WordPress 5.6 (2020): The REST API batch endpoint (/wp-json/batch/v1) is introduced, forming the foundation for the later confusion bug.
• WordPress 6.8: The SQL injection vulnerability (CVE-2026-60137) is present in the core code.
• December 2, 2025: WordPress 6.9 is released. This version inadvertently introduces the batch-route confusion vulnerability (CVE-2026-63030), completing the RCE chain when combined with the existing SQL injection.
• Prior to July 17, 2026: Adam Kues of Assetnote discovers and reports the batch-route confusion to WordPress via HackerOne. Independently, TF1T, dtro, and haongo report the SQL injection.
• July 17, 2026 (Friday): WordPress releases emergency patches:
  • WordPress 6.9.5 (fixes both CVEs, mitigating RCE).
  • WordPress 7.0.2 (fixes both CVEs, mitigating RCE).
  • WordPress 6.8.6 (fixes the SQL injection only, as 6.8 is not susceptible to the batch-route confusion and thus not the RCE chain).
  • WordPress activates its "forced update" mechanism for affected versions, pushing patches to installations configured for auto-updates.
• July 18, 2026 (Saturday):
  • The full technical mechanism of the ‘wp2shell’ attack is publicly disclosed by security researchers.
  • A working proof-of-concept (PoC) exploit for ‘wp2shell’ is made public on GitHub, further increasing the risk of widespread exploitation.
  • CVE IDs (CVE-2026-63030 and CVE-2026-60137) are officially assigned to the vulnerabilities.
  • Cloudflare announces the deployment of Web Application Firewall (WAF) rules to protect its users against the vulnerability.

The rapid succession of patch release, public disclosure, and PoC availability highlights the "race to patch" that often characterizes critical vulnerabilities in widely used software. WordPress’s decision to enable forced updates reflects the extreme urgency they placed on mitigating this threat, recognizing the immense attack surface presented by their platform.

Affected Landscape: Millions of Sites in the Crosshairs

WordPress powers an astounding number of websites globally, with estimates from Searchlight Cyber indicating over 500 million installations. This figure translates to approximately 43% of all websites on the internet, making it by far the most dominant content management system. This sheer scale amplifies the potential impact of any core vulnerability, especially one as severe as ‘wp2shell.’

While the total WordPress install base is vast, the RCE chain specifically targets sites running WordPress 6.9 and 7.0. Given that WordPress 6.9 shipped on December 2, 2025, the vulnerable window covers all installations less than eight months old at the time of disclosure. While an exact number of affected sites within this specific version range is not publicly available, it represents a substantial portion of the active WordPress landscape, likely numbering in the tens of millions or more, depending on update adoption rates. Sites running WordPress 6.8 are exposed only to the SQL injection (CVE-2026-60137) and not the full RCE chain. WordPress 7.1 beta2, which was in development, also carries both fixes, indicating proactive security measures for upcoming releases.

The effectiveness of WordPress’s forced update mechanism is a critical factor in determining the actual blast radius. While designed to push patches quickly, it is not guaranteed to reach all sites, particularly those where auto-updates have been explicitly disabled by administrators for various reasons, such as fear of compatibility issues or custom configurations. This necessitates a strong recommendation for all WordPress administrators to actively verify their current version and ensure the patches (6.9.5, 7.0.2, or 6.8.6) have been successfully applied, rather than passively assuming the forced update landed.

Discrepancies in Scoring and True Risk Assessment

A notable point of concern for security professionals is the discrepancy in how the ‘wp2shell’ vulnerabilities are scored and perceived. WordPress’s own advisory rates the RCE chain as "Critical," reflecting the severity of unauthenticated code execution. However, the official CVE record for CVE-2026-63030 (the batch-route confusion) assigns it a score of 7.5, classifying it as "High" severity. Furthermore, the impact metrics for this CVE primarily credit data access alone, rather than the full integrity or availability loss that would typically be associated with remote code execution. This is because the scoring mechanism, in this instance, treats the route confusion as a parsing flaw in isolation.

In contrast, the SQL injection vulnerability (CVE-2026-60137) is rated with scores higher than 9.1, unequivocally placing it in the "Critical" category. This is largely due to its direct reach into the database, allowing for sensitive data manipulation or extraction.

This divergence in scoring highlights a critical point: the RCE chain’s true impact is greater than the sum of its individual parts when scored in isolation. Security professionals are advised to track both CVEs closely and understand their combined effect rather than relying solely on the individual scores or a generalized "RCE" label. The practical reality is that the chain enables full site compromise, irrespective of how individual components are formally rated. This distinction is crucial for organizations to accurately assess their risk posture and prioritize remediation efforts.

Mitigation Strategies: Patching is Paramount

The most effective and immediate mitigation for the ‘wp2shell’ vulnerability is to update WordPress to the patched versions: 6.9.5, 7.0.2, or 6.8.6 (for the SQL injection only). Webmasters should not delay this process.

Beyond patching, a specific condition offers an interesting, albeit partial, mitigation for the RCE path. Cloudflare, which promptly shipped Web Application Firewall (WAF) rules to protect its customers, noted that the code-execution path works only when the WordPress site is not running a persistent object cache. A persistent object cache, such as Redis or Memcached, stores frequently accessed data in memory, significantly speeding up WordPress performance. A default WordPress installation does not utilize a persistent object cache, meaning default-install exposure to the RCE remains high. Sites fronting WordPress with Redis or Memcached might inadvertently be protected from the RCE path due to how these caching mechanisms interact with the vulnerable process. However, it is crucial to understand that this is merely a side effect and not a fix. Moreover, the presence of a persistent object cache does not protect against the underlying SQL injection vulnerability (CVE-2026-60137). Therefore, relying on caching as a primary defense is ill-advised; patching remains the only comprehensive solution.

For administrators who cannot immediately apply the patch due to operational constraints or testing requirements, temporary stopgap measures can be implemented. These mitigations focus on preventing anonymous callers from reaching the vulnerable batch endpoint (/wp-json/batch/v1). Methods include:

• Web Application Firewall (WAF): Implementing WAF rules to block requests to /wp-json/batch/v1 from unauthenticated users.
• .htaccess or Nginx Configuration: Adding rules to server configurations to restrict access to the batch endpoint. For Apache users, a .htaccess rule could deny access to the specific URL path. Nginx users can achieve similar protection through their server block configurations.

It is critical to note that these temporary mitigations are precisely that – temporary. They are not a substitute for applying the official patches and carry the risk of breaking legitimate integrations or functionalities that rely on the batch API. Webmasters must carefully assess the potential impact before implementing such blocks.

The Broader Threat Landscape and Implications

The emergence of ‘wp2shell’ is a stark reminder of the ongoing security challenges facing widely adopted open-source platforms. Mass exploitation of WordPress vulnerabilities has become an established "industry" for threat actors. Earlier in the year, a server linked to the ‘WP-SHELLSTORM’ crew revealed their successful compromise of over 17,000 sites through a caching-plugin flaw. That particular bug was already public, patched, and only exploitable under a non-default setting. ‘wp2shell,’ in contrast, is a core vulnerability, works on default settings, and enables unauthenticated RCE. This combination makes it exceptionally dangerous.

The race between patch deployment and exploitation is a constant in cybersecurity. WordPress’s decision to push forced updates was an aggressive move to win this race, but the public availability of the full mechanism and a working PoC means that sophisticated attackers now have a clear map to the vulnerability. While the vulnerability is not yet listed on CISA’s Known Exploited Vulnerabilities (KEV) catalog—which requires confirmed, in-the-wild exploitation—this offers only thin comfort. Security vendors like Rapid7 have announced that authenticated checks for InsightVM and Nexpose will be available by July 20, allowing organizations to scan for the vulnerability. However, unauthenticated scanning and exploitation attempts are likely already underway by malicious actors.

The implications of ‘wp2shell’ are far-reaching. For individual website owners, a successful exploit means complete loss of control, potential data theft, website defacement, or the site being used as a platform for further attacks (e.g., malware distribution, phishing). For businesses, this translates to reputational damage, financial losses, and potential regulatory non-compliance. The incident also underscores the critical importance of robust security practices, including:

• Vigilant Patch Management: Regularly checking for and applying updates immediately.
• Security Monitoring: Implementing systems to detect unusual activity or compromise attempts.
• Web Application Firewalls: Utilizing WAFs as an additional layer of defense.
• Regular Backups: Ensuring complete and recoverable backups are maintained.

As the update rollout continues, WordPress’s internal version statistics will eventually reveal how many sites successfully applied the patch. Concurrently, network security teams will be monitoring scan traffic targeting the /wp-json/batch/v1 endpoint, providing insight into the volume of attackers actively seeking to exploit this flaw. The outcome of this race – which curve proves steeper, patching or exploitation – will ultimately determine how this critical WordPress vulnerability is remembered in the annals of cybersecurity.