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

An anonymous HTTP request can now execute arbitrary code on a WordPress site, a critical vulnerability residing deep within the platform’s core. This severe flaw, dubbed "wp2shell," stems from a chain of two distinct bugs and renders even a bare WordPress installation, devoid of any plugins, immediately exploitable. Until Friday, July 17, 2026, all WordPress sites running versions 6.9 and 7.0 were within the exploitation window. The situation prompted WordPress to deploy urgent patches – versions 6.9.5 and 7.0.2 – leveraging its auto-update system for a forced distribution to mitigate the widespread threat. As of Saturday, July 18, 2026, the full exploit mechanism has been publicly disclosed, complete with a working proof-of-concept (PoC) now available on GitHub, escalating the urgency for site administrators globally.

Unpacking the ‘wp2shell’ Vulnerability: A Chained Attack

The "wp2shell" attack is not a singular flaw but a sophisticated exploit chain comprising two critical vulnerabilities, each now assigned a distinct Common Vulnerabilities and Exposures (CVE) identifier. The first component, CVE-2026-63030, relates to a batch-route confusion flaw within the WordPress REST API. The second, CVE-2026-60137, is a classic SQL injection vulnerability discovered in WordPress core. When these two vulnerabilities are chained together, they allow an unauthenticated attacker to achieve remote code execution (RCE) with nothing more than a specially crafted HTTP request. This means an attacker doesn’t need to be logged in, nor does the site require any specific configuration beyond a default installation of the affected versions.

The discovery of the batch-route confusion bug, CVE-2026-63030, is credited to Adam Kues of Assetnote, the attack surface management division of Searchlight Cyber. Kues responsibly reported the vulnerability through WordPress’s official HackerOne bug bounty program. Concurrently, the SQL injection bug, CVE-2026-60137, was independently reported by a group of researchers identified as TF1T, dtro, and haongo. Searchlight Cyber initially maintained a degree of reticence regarding the full technical details of the exploit in their preliminary advisory, directing site owners to a checker tool at wp2shell.com. However, the open-source nature of WordPress meant that once the patches were released, other security researchers quickly reverse-engineered the fixes, leading to the rapid publication of the complete exploit mechanism and a public proof-of-concept on GitHub, effectively nullifying any attempts to delay full disclosure.

Technical Deep Dive: How the Exploit Works

To fully grasp the gravity of "wp2shell," it’s essential to understand the intricate dance between these two vulnerabilities. The core mechanism hinges on manipulating two fundamental WordPress components: the REST API’s batch endpoint and the WP_Query class.

The batch endpoint, specifically /wp-json/batch/v1, has been a part of WordPress since version 5.6, released in 2020. Its purpose is to allow multiple sub-requests to be processed within a single API call, enhancing efficiency. The batch-route confusion, new to WordPress 6.9, exploits a critical error in how this endpoint handles and tracks these concurrent sub-requests. The vulnerability arises when an error occurs in one of the sub-requests. Instead of gracefully failing or properly realigning, this error causes the internal arrays that track the requests and their corresponding handlers to become desynchronized, shifting by one position. This desynchronization allows an attacker’s malicious input, intended for one handler, to be mistakenly processed by a different handler, effectively bypassing the endpoint’s internal allow-list and security checks.

This misdirection is crucial because it enables the attacker to feed arbitrary input into the second part of the chain: the SQL injection vulnerability. This injection specifically targets the author__not_in parameter within WordPress’s WP_Query class. WP_Query is a fundamental component responsible for fetching posts, pages, and custom post types from the database. The author__not_in parameter is designed to exclude posts by specific authors, expecting an array of author IDs. The SQL injection vulnerability arises because if a string (rather than the expected array) is supplied to this parameter, a critical validation check is bypassed. This oversight allows the raw, unsanitized string value to be directly inserted into the SQL query, opening the door for classic SQL injection techniques. By injecting malicious SQL, an attacker can manipulate the database, extract sensitive information, or, more critically in this chained exploit, pave the way for remote code execution.

The ability to deliver an unauthenticated string to this vulnerable WP_Query parameter via the REST API’s batch endpoint, thanks to the route confusion, is what elevates a bounded SQL injection into a full pre-authentication RCE. This chaining transforms a potentially severe but contained database vulnerability into a weapon for complete system compromise.

Affected Versions, Patching, and Forced Updates

The scope of the "wp2shell" vulnerability is broad but segmented, depending on which part of the exploit chain applies. The SQL injection (CVE-2026-60137) is present in WordPress core dating back to version 6.8. However, the batch-route confusion (CVE-2026-63030), the crucial component that converts the injection into unauthenticated RCE, was introduced with WordPress 6.9. This means the full RCE chain primarily impacts more recent installations.

The affected versions and their respective patches are as follows:

• WordPress 6.9.x: Versions prior to 6.9.5 are vulnerable to the full RCE chain. The fix is included in 6.9.5.
• WordPress 7.0.x: Versions prior to 7.0.2 are vulnerable to the full RCE chain. The fix is included in 7.0.2.
• WordPress 6.8.x: Versions prior to 6.8.6 are vulnerable to the SQL injection alone. The fix for the SQL injection is in 6.8.6. Sites running 6.8.x are not exploitable for RCE through this specific chain because they lack the batch-route confusion flaw.
• WordPress 7.1 beta2: This upcoming version already incorporates both fixes.

In an unprecedented move reflecting the severity of the threat, WordPress enabled "forced updates" through its auto-update system for versions 6.9 and 7.0 on Friday, July 17, 2026. This aggressive patching strategy aims to rapidly secure a significant portion of the affected install base. However, WordPress has not confirmed whether this forced push overrides user settings for those who have explicitly disabled auto-updates. Consequently, site administrators are strongly advised to verify their current WordPress version and ensure the appropriate patches have been applied, rather than relying solely on the assumption of an automatic update. Given that WordPress 6.9 was released on December 2, 2025, any site exposed to the full RCE path is running a relatively recent release, less than eight months old, highlighting the rapid lifecycle of new vulnerabilities in widely used software.

Severity and CVE Scoring Discrepancy

The assessment of the "wp2shell" vulnerability presents an interesting discrepancy in its severity ratings. WordPress’s own advisory, published on GitHub, rates the entire RCE chain as "Critical." This aligns with the industry’s understanding that unauthenticated remote code execution is among the most severe types of vulnerabilities, granting an attacker complete control over the compromised system.

However, the CVE records for the individual components tell a slightly different story. CVE-2026-63030 (the REST API batch-route confusion) is scored 7.5, classifying it as "High" severity. Its impact metrics primarily credit data access, rather than the integrity or availability loss typically associated with full code execution. In contrast, CVE-2026-60137 (the SQL injection) receives a score higher than 9.1, unequivocally placing it in the "Critical" category. This disparity arises because standard CVE scoring often evaluates vulnerabilities in isolation. The SQL injection, by its nature, directly impacts the confidentiality, integrity, and availability of the database, leading to a high score. The batch-route confusion, when considered in isolation, might be viewed as a parsing or logic flaw, hence its lower score.

This highlights a crucial point for security professionals: relying solely on individual CVE scores can be misleading when vulnerabilities are chained. The overall impact of the "wp2shell" chain is indeed Critical, as affirmed by WordPress itself, despite one of its constituent CVEs having a "High" rating. It underscores the necessity of understanding the full exploit mechanism rather than just the labels assigned to individual components.

Mitigating Factors and Temporary Workarounds

While the vulnerability is severe, certain environmental factors can slightly alter a site’s exposure profile. One notable condition is the presence of a persistent object cache. According to Cloudflare, which promptly released Web Application Firewall (WAF) rules to protect its customers, the full code-execution path of "wp2shell" is only effective when a WordPress site is not running a persistent object cache. A default WordPress installation typically does not employ such a cache, meaning default-install exposure remains high.

However, sites that utilize solutions like Redis or Memcached as a persistent object cache, often for performance optimization, might be inadvertently protected from the RCE aspect of this specific exploit chain. It is critical to emphasize that this is merely a side effect of how the exploit interacts with caching mechanisms, not a deliberate fix. Furthermore, the presence of a persistent object cache does not mitigate the underlying SQL injection vulnerability (CVE-2026-60137), leaving sites still exposed to potential database compromise.

For administrators unable to apply the patches immediately, Searchlight Cyber provided several temporary mitigation strategies. All these stopgaps revolve around preventing anonymous callers from accessing the /wp-json/batch/v1 REST API endpoint. These include:

• Blocking access at the firewall/WAF level: Implementing rules to deny requests to /wp-json/batch/v1 from untrusted sources.
• Using web server configuration: Configuring Nginx or Apache to block requests to the batch endpoint.
• WordPress filter/plugin: Developing a custom filter or using a security plugin to restrict access to the endpoint.

It is crucial to understand that these are temporary measures and come with significant caveats. Blocking the batch endpoint can disrupt legitimate integrations and functionalities that rely on this API, potentially causing site errors or breaking features. These workarounds are strictly temporary and should be removed once the official patches are applied, as they do not constitute a permanent solution.

Broader Implications and the Race Against Exploitation

The "wp2shell" vulnerability impacts a staggering number of websites. Searchlight Cyber estimates that over 500 million websites globally run on WordPress, underscoring its unparalleled dominance in the content management system market. While not all 500 million sites are running the specific vulnerable versions (6.9+ for RCE, 6.8+ for SQLi), the sheer scale of the platform means that even a fraction of this total represents millions of potentially compromised sites.

The rapid timeline from patch release to public exploit availability highlights the inherent challenges in securing open-source software with a massive user base. WordPress core is open source, meaning its code changes are publicly visible. Once a patch is released, security researchers and malicious actors alike can "diff" the old and new versions to identify the exact code modifications, thereby revealing the underlying vulnerability. This process, often called "patch diffing," allows for the swift creation of exploits. In this case, within a day of the patches being available, researchers had successfully reverse-engineered the fix, published the full exploit mechanism, and released a functional proof-of-concept on GitHub. This scenario validates WordPress’s decision to "pull hard" on the forced update lever, recognizing that the race against exploit development begins the moment a fix is shipped.

The threat of mass exploitation for WordPress vulnerabilities is a well-established industry. Recent history offers stark reminders, such as the "WP-SHELLSTORM" campaign, which exploited a caching-plugin flaw to compromise over 17,000 sites. Critically, that particular bug was already public, patched, and required a non-default setting to be exploitable. "wp2shell" is arguably more dangerous: it affects WordPress core, works on default settings, and its exploit is now public.

Security vendors are quickly responding. Rapid7 announced that authenticated checks for its InsightVM and Nexpose vulnerability management solutions would be available by July 20, enabling organizations to scan their assets for the vulnerability. As of July 18, the vulnerability had not yet been added to CISA’s Known Exploited Vulnerabilities (KEV) Catalog, which lists vulnerabilities with confirmed active exploitation. While this might offer a brief moment of comfort, it is a thin comfort indeed, given the public PoC and the historical speed with which such critical WordPress flaws are weaponized.

The coming days and weeks will be crucial. WordPress’s version statistics will eventually reveal the efficacy of the forced update system and how many sites successfully applied the patches. Simultaneously, security monitoring systems will be watching for a surge in scan traffic targeting the /wp-json/batch/v1 endpoint, indicating the scale of attacker interest. The outcome of this race – which curve is steeper, patching or exploitation – will determine how "wp2shell" is remembered in the annals of cybersecurity incidents.

For all WordPress site owners, the message is clear and urgent: prioritize updating to the latest patched versions (6.9.5, 7.0.2, or 6.8.6 as appropriate) immediately. Verify the update has been successful, and implement temporary mitigations only if an immediate update is absolutely impossible. Staying informed and proactive is the only defense against such pervasive and critical threats.