WordPress Core Vulnerability ‘wp2shell’ Allows Anonymous Code Execution, Patched in Forced Updates

An anonymous HTTP request can now execute code on a WordPress site, a critical vulnerability dubbed "wp2shell" that affects a vast portion of the platform’s user base. The bug resides in the core WordPress software, meaning even a fresh installation without any plugins is susceptible. This exploit impacted all WordPress versions 6.9 and 7.0 until Friday, July 18, 2026, when WordPress released updates 6.9.5 and 7.0.2, triggering its auto-update system to forcibly apply the patches. The vulnerability chain, now officially recognized with CVE IDs, combines a REST API batch-route confusion with a SQL injection flaw, enabling unauthenticated remote code execution (RCE).

Unpacking the wp2shell Vulnerability

The wp2shell vulnerability is not a single bug but a sophisticated two-part exploit. The first component, CVE-2026-63030, identified by Adam Kues at Assetnote, Searchlight Cyber’s attack surface management division, involves a confusion within the REST API’s batch routing mechanism. This discovery was reported through WordPress’s official HackerOne program. The second critical piece, CVE-2026-60137, is a SQL injection vulnerability found deep within WordPress core. This SQL injection flaw was independently reported by a trio of researchers: TF1T, dtro, and haongo. When chained together, these two vulnerabilities create a pathway for an anonymous attacker to achieve complete code execution on a targeted WordPress site.

The implications of this vulnerability are far-reaching. WordPress powers an estimated 500 million websites globally, representing a significant portion of the internet’s digital infrastructure. While not all of these sites are directly exposed to the full RCE chain, the underlying SQL injection flaw has a broader reach, affecting older versions of the software as well. The fact that the exploit can be triggered by an "anonymous user" with "no preconditions" amplifies the severity, as it requires no prior access or authentication to compromise a website.

A Detailed Chronology of Discovery and Mitigation

The timeline of wp2shell’s disclosure and patching highlights the rapid pace of modern cybersecurity threats and responses.

• Prior to July 12, 2026: The vulnerabilities existed undiscovered within WordPress core versions. The SQL injection flaw dates back to WordPress 6.8, while the batch-route confusion, the element that elevates the SQL injection to unauthenticated RCE, was introduced in version 6.9.
• July 12, 2026: Adam Kues from Assetnote, part of Searchlight Cyber, discovered the REST API batch-route confusion and reported it via HackerOne.
• Undisclosed Date (pre-July 18, 2026): TF1T, dtro, and haongo independently reported the SQL injection vulnerability in WordPress core.
• July 15, 2026: The full mechanism of the wp2shell exploit was published online. This publication included a working proof-of-concept (PoC) demonstration, which was made available on GitHub. This act of making the exploit public significantly increased the urgency for patching.
• July 18, 2026: WordPress released critical security updates, version 6.9.5 for WordPress 6.9 and version 7.0.2 for WordPress 7.0. These updates patched both the SQL injection and the batch-route confusion vulnerabilities. Notably, WordPress also enabled its "forced updates" mechanism, ensuring that sites with auto-updates enabled would receive these critical patches automatically.
• July 18, 2026 (Update to Original Article): The article reflects that the two flaws have now been assigned CVE IDs. The full exploit mechanism has been published, a persistent object cache condition has surfaced as a mitigating factor, and a working proof-of-concept is publicly available.

Searchlight Cyber, while detailing the vulnerability under the name "wp2shell," has maintained a degree of technical reticence regarding their own detailed write-up, pointing affected users to a checker at wp2shell.com. However, the release of the patch itself served as a roadmap for other researchers, effectively neutralizing any advantage gained by holding back detailed technical documentation.

Technical Breakdown of the Exploitation Chain

The wp2shell exploit is a carefully constructed chain of events that bypasses WordPress’s security measures.

CVE-2026-60137: The SQL Injection Foundation

The SQL injection vulnerability lies within the WP_Query class, a fundamental component for retrieving data from the WordPress database. Specifically, the flaw is present in the author__not_in parameter. When this parameter is provided with a string value instead of the expected array, WordPress fails to properly sanitize and validate the input. This oversight allows an attacker to inject malicious SQL code directly into the database query. This direct database access grants attackers the ability to read, modify, or delete sensitive data stored within the WordPress database, including user credentials, site content, and configuration settings.

CVE-2026-63030: The Unauthenticated Gateway

The batch-route confusion vulnerability, CVE-2026-63030, is the key that unlocks unauthenticated access to the SQL injection flaw. Introduced in WordPress 6.9, the REST API’s batch endpoint (/wp-json/batch/v1) allows for multiple sub-requests to be processed in a single HTTP call. WordPress manages these sub-requests using two parallel arrays. An error in processing one sub-request can cause these arrays to become desynchronized by one element. This desynchronization leads to a critical security bypass: a subsequent request, intended to be handled by one function, is instead processed by the handler for a different, potentially more privileged, function.

By carefully crafting an anonymous HTTP request to the batch endpoint, an attacker can exploit this desynchronization to bypass access controls and route their malicious input directly to the vulnerable WP_Query parameter. This eliminates the need for any form of authentication, making the attack possible by anyone who can send an HTTP request to the target website. The batch endpoint itself has been part of WordPress since version 5.6, released in 2020, but the specific confusion that enables this exploit is a recent addition in version 6.9.

The Persistent Object Cache Caveat

A crucial mitigating factor that narrows the direct RCE attack surface has been identified: the presence of a persistent object cache. According to analysis from Cloudflare, which has since released Web Application Firewall (WAF) rules to counter the threat, the code-execution path of wp2shell is only effective when a site is not running a persistent object cache like Redis or Memcached. A default WordPress installation typically does not include such caching mechanisms, leaving those sites directly vulnerable to the RCE chain. While sites employing these caching solutions may be shielded from the full RCE exploit, they are still susceptible to the underlying SQL injection vulnerability. This means that even with a cache in place, a site could still suffer data breaches.

Version-Specific Exposure and Patching Strategy

The exposure to the wp2shell vulnerabilities is bifurcated based on WordPress version:

• WordPress 6.8.x: These versions are vulnerable to the SQL injection flaw (CVE-2026-60137) but not to the RCE chain, as the batch-route confusion (CVE-2026-63030) was introduced later. The released patches for these versions primarily address the SQL injection.
• WordPress 6.9.x: These versions are vulnerable to both the SQL injection and the batch-route confusion, making them susceptible to the full unauthenticated RCE chain.
• WordPress 7.0.x: Similarly, these versions are vulnerable to the full RCE chain and have been addressed by the latest updates.

WordPress’s decision to implement forced updates is a significant measure to combat the rapid spread of exploits. This approach aims to ensure that the vast majority of active WordPress sites receive the critical security patches swiftly, regardless of whether their owners have manually enabled auto-updates. However, it remains imperative for site administrators to verify their current WordPress version and confirm that the update has been successfully applied, especially for those who may have intentionally disabled automatic updates. The forced push might not reach sites that have explicitly opted out of automatic updates, leaving them exposed.

Scoring and Impact: A Nuanced Perspective

The scoring of the wp2shell vulnerabilities presents a nuanced view of their severity. WordPress’s internal security advisory rates the full RCE chain as "Critical." However, its Common Vulnerabilities and Exposures (CVE) record assigns a score of 7.5, classifying it as "High." The impact metrics in the CVE record primarily focus on data access, potentially underestimating the full consequences of integrity and availability loss that can result from code execution.

The SQL injection vulnerability itself, when considered independently, receives a higher score, exceeding 9.1, also classified as "Critical." This disparity in scoring highlights a common challenge in vulnerability assessment: the direct database access of a SQL injection can be more straightforwardly quantifiable than the broader implications of code execution, which can vary widely depending on the attacker’s intent and the compromised system’s configuration. Security professionals are advised to track both CVEs individually, rather than relying solely on the "Critical RCE" label, to fully grasp the scope of the threat.

Broader Implications and Industry Reactions

The wp2shell incident underscores the persistent challenges in securing the global WordPress ecosystem. With over 500 million websites running on the platform, even minor vulnerabilities can have widespread repercussions. The speed at which a proof-of-concept exploit became publicly available after the patch release highlights the race against time that WordPress and its users face.

Rapid7 has announced that authenticated checks for its InsightVM and Nexpose vulnerability scanners will include wp2shell starting July 20, 2026. While the vulnerability is not yet listed on CISA’s Known Exploited Vulnerabilities (KEV) catalog—a list of vulnerabilities with confirmed exploitation—and no exploitation has been officially reported as of July 18, 2026, this comfort is considered "thinner than it reads." The public availability of a working exploit often precedes widespread, confirmed exploitation.

The history of WordPress vulnerabilities reveals a pattern of mass exploitation. A previous flaw in a caching plugin, for instance, allowed the "WP-SHELLSTORM" crew to compromise over 17,000 sites, despite being publicly known and patched, and only working on a non-default setting. The wp2shell vulnerability is particularly concerning because it is public, patched, and, in its RCE form, works on the default installation, significantly lowering the barrier to entry for attackers.

Mitigation Strategies for Unpatched Sites

For administrators who cannot immediately update their WordPress installations, Searchlight Cyber offers several mitigation strategies focused on blocking access to the vulnerable batch endpoint. These are considered temporary stopgaps and may disrupt legitimate integrations:

• Web Application Firewall (WAF) Rules: Implementing WAF rules that specifically block or scrutinize requests to /wp-json/batch/v1 can prevent attackers from reaching the vulnerable component.
• HTTP Request Filtering: Server-level configurations or plugins can be used to filter incoming HTTP requests, identifying and blocking suspicious patterns targeting the batch endpoint.
• Disabling the REST API (with caution): While the REST API offers valuable functionality, disabling it entirely or restricting its access can mitigate the risk. However, this measure should be implemented with extreme caution, as it can break legitimate plugin and theme functionalities that rely on the API.

The Unstoppable Disclosure Cycle

The nature of open-source software development means that security patches inherently contain the blueprint for the vulnerabilities they fix. As soon as WordPress core released the updated files, researchers could analyze the changes and deduce the exact nature of the bugs. This dynamic necessitates a swift patching strategy. WordPress’s decision to enforce updates for auto-update-enabled sites represents a strong move to accelerate patch deployment.

With the exploit now public, the battleground shifts to the speed at which patches are applied versus the speed at which attackers leverage the exploit. WordPress’s version statistics will reveal the adoption rate of the patches, while network traffic analysis targeting the /batch/v1 endpoint will indicate the level of attacker interest. The outcome of this race will ultimately determine the long-term impact and memory of the wp2shell vulnerability.

The global WordPress community, developers, and users are urged to remain vigilant, prioritize security updates, and employ robust security practices to safeguard their online presence against the ever-evolving threat landscape.