WordPress Core Vulnerabilities: Two Flaws Enable Anonymous Code Execution, Patched via Forced Updates

An anonymous HTTP request can now execute code on a WordPress site due to a critical vulnerability chain dubbed "wp2shell." This severe flaw impacts core WordPress functionality, meaning even a freshly installed site without any plugins is potentially exploitable. The vulnerability affected all WordPress versions 6.9 and 7.0 until Friday, July 17, 2026, when WordPress released emergency updates, versions 6.9.5 and 7.0.2, and activated its auto-update system to force the installation of these patches on a significant portion of its user base.

The wp2shell vulnerability is not a single bug but a combination of two distinct but chained vulnerabilities. The first, identified as CVE-2026-63030, is a confusion within the REST API’s batch route. The second, CVE-2026-60137, is a SQL injection flaw deeply embedded within the WordPress core. When exploited in tandem, these vulnerabilities allow an unauthenticated attacker to achieve remote code execution (RCE) on a vulnerable WordPress installation through a single, anonymous HTTP request.

The technical details of this exploit were significantly amplified following Friday’s patch release. The full exploitation mechanism has since been publicly disclosed, and a working proof-of-concept (PoC) exploit has been made available on GitHub, dramatically increasing the immediate threat to unpatched systems.

Discovery and Disclosure Timeline

The initial discovery of the batch-route confusion vulnerability was made by Adam Kues, part of Assetnote, the attack surface management division of Searchlight Cyber. Kues responsibly reported this finding through WordPress’s established HackerOne bug bounty program. The subsequent research, published under the moniker "wp2shell," highlighted the critical nature of the exploit, stating it "has no preconditions and can be exploited by an anonymous user."

Separately, the SQL injection vulnerability was reported by a collective of researchers including TF1T, dtro, and haongo. While Searchlight Cyber has elected to withhold its detailed technical write-up for now, opting to direct website owners to a diagnostic checker at wp2shell.com, the information has become readily accessible. The decision by other researchers to publish their findings and the existence of a functional exploit mean that the window for exploitation has narrowed considerably for those who have not yet updated.

Vulnerability Scope and Versioning

The reach of the wp2shell exploit is intricately tied to specific WordPress versions due to the way the two vulnerabilities manifest. The SQL injection flaw has a deeper historical footprint, dating back to WordPress version 6.8. However, the batch-route confusion, which is the crucial element that transforms a bounded SQL injection into unauthenticated RCE, is present only in versions 6.9 and above.

This versioning creates a tiered risk landscape:

• Versions 6.9 and 7.0: These versions are fully susceptible to the chained wp2shell exploit, leading to unauthenticated remote code execution. The forced updates to 6.9.5 and 7.0.2 were specifically aimed at addressing this critical risk.
• Versions prior to 6.9 (including 6.8): While these versions contain the SQL injection vulnerability (CVE-2026-60137), they are not susceptible to the RCE chain because they lack the batch-route confusion (CVE-2026-63030). WordPress version 6.8.6, for instance, was patched to address the SQL injection component alone, mitigating a high-severity data access risk but not the full RCE.
• WordPress 7.1 beta2: This pre-release version has reportedly incorporated fixes for both vulnerabilities.

A crucial point of clarification is whether WordPress’s forced update mechanism extends to sites that have explicitly disabled the auto-update feature. The platform has not issued a definitive statement on this matter. Therefore, website administrators are strongly advised to verify their current WordPress version manually rather than assuming the patch has been automatically applied.

Impact on the WordPress Ecosystem

With an estimated 500 million websites worldwide running on WordPress, the potential impact of such a core vulnerability is staggering. However, it’s important to distinguish between the total WordPress install base and the subset actually exposed to the full RCE chain. The RCE path, requiring the batch-route confusion, only exists in versions 6.9 and later. Version 6.9 was released on December 2, 2025. This means that any site vulnerable to the full RCE chain is running a version released within the last eight months. The exact number of sites running these specific vulnerable versions remains unconfirmed by official advisories.

Technical Deep Dive into the Exploitation Mechanism

The wp2shell exploit chain is built upon two relatively small, yet critical, misconfigurations within WordPress core.

The SQL Injection: Exploiting WP_Query

The SQL injection vulnerability resides within the WP_Query class, specifically in how it handles the author__not_in parameter. When this parameter is supplied with a string instead of the expected array, a crucial validation check is bypassed. This bypass allows the raw, potentially malicious string input to be directly incorporated into the SQL query executed by WordPress. This direct injection into database queries is the foundation for data exfiltration and manipulation.

The Batch Route Confusion: Bypassing Authentication

The second vulnerability, the batch endpoint confusion, is the key that unlocks unauthenticated access to the SQL injection. The /wp-json/batch/v1 route in WordPress is designed to process multiple sub-requests within a single HTTP call, efficiently managing these requests through two parallel arrays. However, an error occurring within one of these sub-requests can cause the arrays to fall out of synchronization by a single element. This desynchronization is exploited by an attacker to trick the system into processing a subsequent request under the handler intended for a different request.

This "confusion" allows an attacker to bypass the endpoint’s built-in allow-list mechanisms. By carefully crafting the malicious HTTP request, an attacker can deliver their input directly into the vulnerable WP_Query parameter without needing any prior authentication. While the batch endpoint itself has been a feature since WordPress 5.6 (released in November 2020), the specific confusion that enables this exploit is a recent addition, present only in version 6.9.

CVE Scoring and Nuances

The differing characteristics of the two vulnerabilities have led to distinct scoring and advisory ratings, which can be misleading. WordPress’s own security advisory rates the combined RCE chain as "Critical." However, the Common Vulnerabilities and Exposures (CVE) record for the chain assigns a CVSS score of 7.5, classifying it as "High." The impact metrics for this score primarily focus on data access, potentially underestimating the integrity and availability losses associated with full code execution.

Conversely, the SQL injection vulnerability, when considered independently, receives a higher score, exceeding 9.1, placing it in the "Critical" category. This discrepancy arises because the scoring systems often prioritize direct database access and manipulation capabilities. The routing confusion, in isolation, might be categorized as a parsing or logic flaw, whereas the SQL injection has a more immediate and quantifiable impact on data integrity. Security professionals emphasize the importance of tracking both CVEs independently, rather than relying solely on the "critical RCE" label, as the SQL injection poses a significant threat on its own.

Persistent Object Cache Condition

A significant mitigating factor identified by Cloudflare, which has also released Web Application Firewall (WAF) rules in response to the disclosure, is the role of persistent object caches. The remote code execution path of the wp2shell exploit is confirmed to function only when a site is not running a persistent object cache. A default WordPress installation typically does not include such a cache, meaning these sites remain directly vulnerable to the RCE chain.

While sites employing persistent object caches like Redis or Memcached might be shielded from this specific RCE path, this is an incidental defense, not a complete fix. It does not offer protection against the underlying SQL injection vulnerability, which remains a threat regardless of caching mechanisms.

Industry Response and Remediation Efforts

The cybersecurity industry is rapidly mobilizing to address this threat. Rapid7 has announced that authenticated checks for InsightVM and Nexpose will be available by July 20, 2026, allowing organizations to scan their environments for the vulnerability. As of July 18, 2026, the vulnerability had not yet been added to the CISA Known Exploited Vulnerabilities (KEV) catalog, which typically requires confirmed exploitation in the wild. No exploitation incidents have been officially reported as of this date, offering a thin layer of reassurance.

The threat of mass exploitation of WordPress vulnerabilities is a persistent concern. Previously, a flaw in a caching plugin, even though it required a non-default configuration and was already patched, was exploited by the "WP-SHELLSTORM" group to compromise over 17,000 sites. The wp2shell vulnerability, being in core, public, and patched, and working on default installations, presents a significantly higher and more immediate risk.

Mitigation Strategies for Unpatched Systems

For organizations unable to immediately update their WordPress installations, Searchlight Cyber has outlined several interim mitigation strategies. These measures primarily focus on restricting anonymous access to the batch endpoint. However, it is crucial to understand that these are temporary stopgaps and can potentially disrupt legitimate website integrations and functionality.

• Blocking Anonymous Access to the Batch Endpoint: This involves configuring web server rules (e.g., in Apache or Nginx) or using WAFs to deny requests to /wp-json/batch/v1 from unauthenticated users.
• Rate Limiting: Implementing strict rate limiting on the batch endpoint can help deter automated exploitation attempts, though it may not prevent targeted attacks.
• Disabling the REST API (if not essential): For sites that do not rely on the REST API for core functionality, disabling it entirely can be an effective, albeit drastic, measure.

These measures are intended to provide a buffer until the official WordPress updates can be applied.

The Role of Open Source and Disclosure Dynamics

The open-source nature of WordPress, while fostering innovation and transparency, also creates unique challenges in vulnerability disclosure. The release notes for WordPress updates name the specific files that have been modified. This transparency, while beneficial for legitimate development, also provides a roadmap for malicious actors.

Searchlight Cyber’s decision to delay its full technical write-up was an attempt to slow down the exploit development cycle. However, within a day of the patch release, other researchers had analyzed the changes, published the exploitation mechanism, and released a working exploit on GitHub. This rapid dissemination highlights the inherent challenges in managing disclosures for widely adopted open-source software. The act of patching inevitably reveals the location of the vulnerability. The only variable left is the speed at which the patch can be deployed to the global user base before it is weaponized. WordPress’s decision to implement forced updates on Friday was a clear attempt to accelerate this deployment process.

The Future Landscape

The ongoing race between exploit development and patch deployment is now in full swing. WordPress’s version statistics will provide insight into the adoption rate of the latest patches. Simultaneously, monitoring network traffic for requests targeting the /batch/v1 endpoint will reveal the extent of active exploitation attempts. The relative steepness of these two curves will ultimately determine the long-term impact and notoriety of the wp2shell vulnerability. Website owners are urged to prioritize updating their WordPress installations to the latest secure versions to safeguard against this critical threat.