Critical Remote Code Execution Vulnerability Uncovered in WordPress Core, Prompting Urgent Updates Across Millions of Sites

An alarming security flaw has been discovered within the very core of WordPress, enabling an anonymous HTTP request to execute arbitrary code on affected websites. This critical vulnerability, designated ‘wp2shell,’ requires no prior authentication and can be exploited on a bare WordPress installation without any plugins. The discovery has sent ripples through the cybersecurity community, prompting rapid responses from WordPress developers and security researchers alike. Versions 6.9 and 7.0 were initially within the primary exploitation range until Friday, July 17, 2026, when WordPress initiated "forced updates" through its auto-update system, releasing versions 6.9.5 and 7.0.2 to mitigate the threat.

A Chained Exploit: Two Vulnerabilities, One Critical Outcome

The ‘wp2shell’ exploit is not a singular flaw but a sophisticated chain of two distinct vulnerabilities, both of which now carry official CVE (Common Vulnerabilities and Exposures) IDs. The first, CVE-2026-63030, relates to a REST API batch-route confusion. The second, CVE-2026-60137, is a SQL injection vulnerability residing in WordPress core. When leveraged in sequence, these two bugs facilitate a complete bypass of authentication mechanisms, leading directly to remote code execution (RCE) from an unauthenticated request.

The full technical mechanism of the exploit has been published, and a working proof-of-concept (PoC) is now publicly available on GitHub, escalating the urgency for site administrators to ensure their installations are patched. The rapid public disclosure of the PoC, occurring within a day of the patch release, underscores the inherent challenge in securing widely used open-source platforms; once a fix is public, the path to exploit is often quickly reverse-engineered by other researchers or malicious actors.

Discovery and Disclosure Timeline

The initial discovery of the batch-route confusion vulnerability (CVE-2026-63030) is credited to 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, a crucial mechanism for identifying and addressing security issues before they are widely exploited.

Separately, the SQL injection component (CVE-2026-60137) was reported by a collaborative effort of researchers identified as TF1T, dtro, and haongo. The coordinated disclosure and subsequent patching efforts highlight the collaborative nature of cybersecurity, involving independent researchers, security firms, and core development teams.

Searchlight Cyber’s public write-up, titled ‘wp2shell,’ explicitly stated that the attack had "no preconditions and can be exploited by an anonymous user," emphasizing the severity of the threat. While Searchlight initially held back its full technical write-up, pointing site owners to a checker tool at wp2shell.com, the details of the exploit inevitably emerged from analysis of the released patches themselves. For open-source software like WordPress, distributing a fix inherently provides a roadmap to the vulnerability it addresses, making a rapid deployment strategy paramount.

Technical Breakdown of the Exploit Chain

Understanding the individual components of the ‘wp2shell’ chain is crucial for comprehending its impact.

1. The SQL Injection (CVE-2026-60137):
This vulnerability is rooted in WordPress’s WP_Query class, specifically within the author__not_in parameter. Normally, this parameter expects an array of author IDs. However, the flaw arises when a string value is supplied instead of an array. A check designed to validate array input is bypassed under these conditions, allowing the raw, unvalidated string to be directly injected into the SQL query. This gives an attacker the ability to manipulate database queries, potentially extracting sensitive information or altering data. The SQL injection bug has a broad reach, extending back to WordPress version 6.8, indicating its presence across a significant number of active installations.

2. The REST API Batch-Route Confusion (CVE-2026-63030):
This component is the linchpin that elevates the SQL injection from an authenticated database compromise to an unauthenticated remote code execution. The vulnerability lies within WordPress’s /wp-json/batch/v1 REST API endpoint. Introduced in WordPress 5.6 (December 2020), this batch endpoint is designed to process multiple sub-requests within a single API call, improving efficiency. Internally, it manages these sub-requests using two parallel arrays. The confusion occurs when an error is triggered in one of these sub-requests. This error causes the two parallel arrays to fall out of sync by one position. Consequently, a malicious request can then be processed by the handler intended for a different, legitimate request. This "route confusion" allows an attacker to bypass the endpoint’s internal allow-list, injecting their input directly into the vulnerable WP_Query parameter (the author__not_in parameter of the SQL injection), all without requiring any form of authentication. Crucially, this batch-route confusion vulnerability is specific to WordPress versions 6.9 and later, meaning the full RCE chain is only viable against these newer installations.

Chaining for Unauthenticated RCE:
The elegance and severity of ‘wp2shell’ lie in how these two flaws are combined. An anonymous attacker first crafts a request to the /wp-json/batch/v1 endpoint. Within this batch request, they embed a specially malformed sub-request designed to trigger the array desynchronization (CVE-2026-63030). This desynchronization then redirects a subsequent, malicious input containing the SQL injection payload (CVE-2026-60137) into the author__not_in parameter of WP_Query. Because the batch endpoint bypasses authentication and the SQL injection bypasses input validation, the attacker gains unauthenticated access to database manipulation, which can then be escalated to full remote code execution by leveraging database functions to write and execute arbitrary PHP code on the server.

Scope of Impact and Affected Systems

The sheer scale of WordPress’s global footprint makes any core vulnerability a matter of extreme concern. Estimates suggest that over 500 million websites currently run on WordPress, representing approximately 43% of all websites on the internet. This makes it the most widely used Content Management System (CMS) by a significant margin.

While the total install base is massive, it’s important to delineate the exact scope of this particular RCE vulnerability. The full code-execution chain, relying on both CVEs, is only exploitable on WordPress sites running version 6.9 or newer. WordPress 6.9 was released on December 2, 2025, meaning sites exposed to the full RCE path are running a relatively recent release, less than eight months old at the time of discovery. The exact number of sites within this specific window is not publicly available, but given WordPress’s rapid adoption rates, it is undoubtedly in the tens of millions.

For older versions, specifically 6.8, while not vulnerable to the full RCE chain due to the absence of the batch-route confusion, they remain susceptible to the SQL injection (CVE-2026-60137) alone. WordPress has addressed this by releasing 6.8.6, which patches only the SQL injection, acknowledging its independent severity. WordPress 7.1 beta2, the upcoming development release, already includes both fixes, demonstrating a forward-looking security posture.

A critical nuance regarding the RCE path is its interaction with persistent object caching. According to Cloudflare, which quickly rolled out Web Application Firewall (WAF) rules to protect its users, the code-execution path functions only when a site is not running a persistent object cache. Many high-traffic WordPress sites utilize persistent object caches like Redis or Memcached to improve performance. While this might offer a partial shield against the RCE for these specific setups, it is a side effect of their caching architecture, not a direct fix. Crucially, this caching configuration does not mitigate the underlying SQL injection vulnerability, leaving those sites still exposed to potential database compromise. Furthermore, a default WordPress installation does not typically employ a persistent object cache, meaning the vast majority of out-of-the-box sites running 6.9 or 7.0 are fully exposed to the RCE.

Official Responses and Industry Reactions

WordPress’s response to the disclosure was swift, emphasizing the critical nature of the vulnerability. The decision to implement "forced updates" through its auto-update system for affected versions underscores the severity and the urgency for widespread patching. This mechanism ensures that a significant portion of the vulnerable install base receives the necessary security patches without requiring manual intervention from site administrators. However, it remains unclear whether these forced updates successfully reach sites where administrators have explicitly disabled auto-updates. This highlights the ongoing responsibility of site owners to actively verify their WordPress version and ensure all patches are applied.

The official advisory from WordPress on GitHub (GHSA-ff9f-jf42-662q) rates the full RCE chain as "Critical." However, a curious discrepancy emerges in the individual CVE scores. The CVE record for the RCE component (CVE-2026-63030) scores it at 7.5 (High severity), attributing impact primarily to data access, rather than the integrity or availability loss typically associated with code execution. In contrast, the SQL injection (CVE-2026-60137) receives a score higher than 9.1 (Critical severity), reflecting its direct and profound impact on database integrity. This disparity in scoring, where the component leading to the "lesser" outcome (direct database access) receives a higher CVSS score than the component enabling the "greater" outcome (RCE), can be attributed to how CVSS (Common Vulnerability Scoring System) evaluates individual vulnerabilities in isolation versus their potential in a chain. Security experts advise tracking both CVEs closely, rather than relying solely on the labels or individual scores, to fully grasp the combined risk.

The cybersecurity industry reacted promptly. Cloudflare, a leading content delivery network and security provider, announced that it had shipped Web Application Firewall (WAF) rules to protect its customers against the ‘wp2shell’ exploit alongside the public disclosure. This immediate action by security vendors is crucial in providing a temporary shield for sites that may not be able to patch instantly. Rapid7, a prominent security intelligence firm, confirmed that authenticated checks for its InsightVM and Nexpose vulnerability management solutions would be available by July 20, allowing organizations to scan their WordPress environments for the vulnerability.

As of July 18, the vulnerability has not yet been added to CISA’s (Cybersecurity and Infrastructure Security Agency) Known Exploited Vulnerabilities (KEV) Catalog. Inclusion in the KEV catalog typically requires confirmed evidence of active, widespread exploitation in the wild. While this might offer a sliver of comfort, it is a "thinner than it reads" assurance, as the public availability of a working PoC significantly increases the likelihood of imminent mass exploitation. Attackers often move swiftly once such information becomes public.

Broader Implications and Lessons Learned

The ‘wp2shell’ vulnerability serves as a stark reminder of the persistent and evolving threat landscape facing popular web platforms. The sheer volume of WordPress installations makes it an attractive target for malicious actors, who constantly seek new ways to compromise sites for various nefarious purposes, including data theft, defacement, spam distribution, and botnet recruitment.

This incident echoes previous mass exploitation campaigns targeting WordPress. For instance, before its server was leaked in June, the "WP-SHELLSTORM" group reportedly compromised over 17,000 sites using a flaw in a caching plugin. Critically, that particular bug was already public, patched, and only exploitable under a non-default setting. In contrast, ‘wp2shell’ is public, patched, but crucially, it works on a default setting and requires no authentication, making its potential for widespread impact exponentially higher. This elevates ‘wp2shell’ to a truly critical event for the WordPress ecosystem.

The race between patch deployment and exploit development is a constant feature of the cybersecurity world. In open-source environments, once a fix is released, security researchers and malicious actors alike can reverse-engineer the patch to understand the underlying vulnerability. This necessitates an incredibly rapid patching cycle from the moment a vulnerability is confirmed to the moment patches are deployed and, ideally, automatically applied. WordPress’s use of forced updates demonstrates an aggressive, necessary approach to minimize the window of opportunity for attackers.

For site administrators unable to update immediately, temporary mitigation strategies are available, though they come with caveats. Searchlight Cyber suggests blocking anonymous callers from accessing the /wp-json/batch/v1 endpoint. This can be achieved through various means, such as web server configurations (e.g., Apache .htaccess rules, Nginx configurations) or WAF rules. However, these are stopgap measures and carry the risk of breaking legitimate integrations or functionalities that rely on the batch API. They are not substitutes for applying the official security update.

Ultimately, the long-term security of the WordPress ecosystem hinges on several factors: the continued vigilance of security researchers, the responsiveness of the WordPress core development team, and the proactive engagement of site administrators in maintaining up-to-date installations. The ‘wp2shell’ incident will undoubtedly be a case study in how quickly a critical vulnerability in widely-used software can move from discovery to public exploit, and how effectively the community can respond to protect its vast user base. The coming weeks will reveal whether the rapid patching efforts outpaced the efforts of attackers seeking to exploit this significant flaw.