WordPress Core Vulnerabilities "wp2shell" Enable Unauthenticated Remote Code Execution via Chained Exploits

An anonymous HTTP request can now execute arbitrary code on a WordPress site, a critical vulnerability that affects core functionality and requires no plugins to exploit. The bug, dubbed "wp2shell," stems from a combination of two distinct flaws, both of which have now been assigned CVE identification numbers. The first, CVE-2026-63030, involves a confusion within the REST API’s batch routing mechanism, while the second, CVE-2026-60137, is a SQL injection vulnerability present in WordPress core. When chained together, these vulnerabilities allow an unauthenticated attacker to achieve remote code execution (RCE) on vulnerable systems. This widespread threat loomed over all WordPress sites running versions 6.9 and 7.0 until Friday, July 18, 2026, when WordPress proactively released security updates 6.9.5 and 7.0.2, leveraging its auto-update system to enforce patches on a significant portion of its user base.

The gravity of this situation was amplified as the full exploitation mechanism became publicly available, and a functional proof-of-concept exploit was released on GitHub shortly after WordPress began deploying its fixes. This rapid dissemination of technical details underscores the constant race between vulnerability disclosure and patching in the cybersecurity landscape.

Genesis of the Vulnerability: Discovery and Disclosure

The initial discovery of the batch-route confusion vulnerability was made by Adam Kues, affiliated with Assetnote, the attack surface management division of Searchlight Cyber. Kues responsibly reported the flaw through WordPress’s established HackerOne bug bounty program. Searchlight Cyber later published a detailed write-up under the moniker "wp2shell," emphasizing that the exploit carries "no preconditions and can be exploited by an anonymous user." The SQL injection component, on the other hand, was reported independently by a trio of researchers: TF1T, dtro, and haongo.

Searchlight Cyber has maintained a degree of technical reticence regarding its own in-depth analysis, opting instead to direct website owners to a dedicated checker at wp2shell.com. However, this strategic approach has been somewhat undermined by the public availability of the patch and the subsequent scrutiny by other security researchers who have effectively reverse-engineered the fix.

Understanding the Technical Exploitation Chain

The wp2shell exploit is a sophisticated two-stage attack that hinges on the interplay between the REST API batch endpoint and a specific parameter within the WP_Query class.

1. The SQL Injection (CVE-2026-60137): This vulnerability lies within the WP_Query class, a fundamental component of WordPress for database queries. Specifically, the author__not_in parameter is susceptible. When this parameter is provided with a string value instead of the expected array, a crucial validation check is bypassed. This allows raw, unsanitized input to be directly incorporated into SQL queries. This direct access to the database is highly dangerous, potentially allowing attackers to extract sensitive information, modify data, or even compromise the integrity of the entire database. This injection vulnerability has a broader reach, impacting WordPress versions as far back as 6.8.

2. The REST API Batch Route Confusion (CVE-2026-63030): This vulnerability is the key to transforming the SQL injection from a potentially authenticated attack vector into a fully unauthenticated remote code execution. The /wp-json/batch/v1 route in WordPress’s REST API is designed to process multiple sub-requests within a single HTTP call. It manages these requests using two parallel arrays. However, an error in the handling of one sub-request can cause these arrays to fall out of synchronization by one element. This desynchronization is critical: it means a subsequent request, intended for one handler, might instead be processed by a different handler.

When an attacker crafts a malicious request targeting the batch endpoint, they can leverage this confusion to bypass the endpoint’s allow-list and ensure their input, containing the crafted SQL injection payload, reaches the vulnerable WP_Query parameter. This bypass is the crucial step that removes the authentication requirement, enabling anonymous exploitation. The batch endpoint itself has been part of WordPress core since version 5.6, released in November 2020. However, the specific confusion that allows for this abuse is a more recent addition, present only in WordPress version 6.9 and later.

Versioning and Exposure: A Divided Threat Landscape

The differing version ranges affected by each component of the wp2shell vulnerability create a nuanced picture of exposure:

• WordPress versions 6.8.x: These versions are vulnerable to the SQL injection (CVE-2026-60137) alone. While this is a serious security concern, it does not, by itself, lead to unauthenticated RCE. WordPress 6.8.6 specifically addresses this injection vulnerability.
• WordPress versions 6.9.x: These versions are vulnerable to both the SQL injection and the batch-route confusion. This combination is what enables the unauthenticated RCE. The batch-route confusion was introduced in version 6.9.
• WordPress versions 7.0.x: Similar to version 6.9, these versions are also susceptible to the chained exploit.

WordPress security update 6.9.5 and 7.0.2, released on Friday, July 18, 2026, address both vulnerabilities. The development team has confirmed that version 7.1 beta2 also incorporates these critical fixes. The decision to enable "forced updates" via the auto-update system is a significant measure, aiming to rapidly patch as many vulnerable sites as possible before attackers can fully weaponize the publicly available exploit details.

The full install base of WordPress is estimated to be over 500 million websites. However, the RCE chain is only present from version 6.9 onwards, which was released on December 2, 2025. This means that any site exposed to the code-execution path is running a release that is less than eight months old. The exact number of sites running these vulnerable versions remains unconfirmed by official advisories.

Scoring and Severity: A Disconnect in Perception

The official WordPress security advisory rates the complete RCE chain as "Critical." However, the Common Vulnerabilities and Exposures (CVE) record for the combined exploit assigns a score of 7.5, categorized as "High." This discrepancy highlights a potential underestimation of the RCE’s impact, as the CVE metrics primarily credit data access rather than the full extent of integrity and availability loss typically associated with code execution.

The SQL injection vulnerability itself, when considered in isolation, receives a higher score, exceeding 9.1, also designated as "Critical." This scoring emphasizes the direct database access and manipulation capabilities of the injection. Security experts urge administrators to track both CVEs individually rather than relying solely on the broad "critical RCE" label. The underlying technical details and the potential for exploitation should be the primary focus, as the scoring system may not fully capture the real-world risk.

A Limiting Factor: Persistent Object Caching

A notable condition that can mitigate the risk of the RCE path is the presence of a persistent object cache, such as Redis or Memcached. According to analysis from Cloudflare, which has also released Web Application Firewall (WAF) rules to counter the exploit, the code-execution path specifically fails when a site is actively using such a caching mechanism. A default WordPress installation, which typically lacks a persistent object cache, therefore remains fully exposed to this RCE vector.

It is crucial to understand that while persistent object caching may prevent the RCE exploit, it does not protect against the underlying SQL injection vulnerability (CVE-2026-60137). Therefore, even sites employing object caching are still at risk of data compromise or manipulation.

Official Responses and Broader Implications

The WordPress security team’s swift action in releasing patches and enabling forced updates demonstrates a commitment to addressing critical vulnerabilities. However, the question remains whether these forced updates will reach sites where administrators have explicitly disabled the auto-update functionality. Website owners are strongly advised to verify their current WordPress version rather than assuming the patch has been automatically applied.

As of July 18, 2026, the exploit has not been added to the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog, which requires confirmed exploitation in the wild. No exploitation incidents have been publicly reported yet. However, this lack of immediate reporting does not diminish the threat, especially given the public availability of the exploit.

The cybersecurity industry is well aware of the potential for mass exploitation of WordPress. Previously, a flaw in a caching plugin led to the WP-SHELLSTORM campaign, compromising over 17,000 sites. That exploit targeted a non-default setting, was publicly known, and had already been patched. The wp2shell vulnerability, in contrast, affects the core software, works on default configurations, and is now publicly disclosed with a working exploit.

Mitigation Strategies for Sites Unable to Update Immediately

For administrators who cannot immediately update their WordPress installations, Searchlight Cyber has outlined several temporary mitigation strategies. These measures primarily focus on restricting access to the batch endpoint, thereby preventing anonymous callers from triggering the exploit chain. However, it is important to note that these are stopgap solutions and may inadvertently break legitimate integrations or functionalities.

These mitigation strategies include:

• Web Application Firewall (WAF) Rules: Implementing WAF rules specifically designed to block or challenge requests to the /wp-json/batch/v1 endpoint.
• Access Control Lists (ACLs): Configuring server-level ACLs to deny access to the batch endpoint from untrusted IP addresses.
• Plugin-Based Restrictions: Utilizing security plugins that offer granular control over REST API endpoints and can be configured to block access to the batch route.

These measures serve as temporary shields until a permanent solution, the software update, can be applied.

The Race Against Time: Patching and Exploitation

The open-source nature of WordPress means that its code is publicly available, and release notes often detail the files that have been modified. While Searchlight Cyber initially withheld its full technical write-up, the release of the patch itself provided enough information for other researchers to reconstruct the exploit mechanism and publish proof-of-concept code. This scenario highlights a fundamental challenge in software security: it is often impossible to ship a fix without also providing a roadmap to the vulnerability.

The only effective lever remaining is the speed at which the patch can be deployed to the global user base. WordPress’s decision to enforce updates through its auto-update system on Friday was a forceful attempt to close this window of opportunity for attackers.

Now, with the exploit publicly available and updates still rolling out, the cybersecurity community will be closely watching two key metrics: WordPress’s version statistics to gauge the adoption rate of the patch, and network traffic analysis for the /wp-json/batch/v1 endpoint to identify attackers actively scanning for vulnerable sites. The relative steepness of these two curves will ultimately determine how this critical vulnerability, wp2shell, is remembered in the annals of cybersecurity. The continued vigilance of website administrators and security professionals is paramount in mitigating the potential fallout from this significant security threat.