WordPress Core Vulnerabilities, wp2shell, Lead to Unauthenticated Remote Code Execution

Updated July 18, 2026: The two critical vulnerabilities affecting WordPress core, collectively dubbed "wp2shell," have been officially assigned CVE IDs, and a detailed technical breakdown of their exploitation mechanism has been published. A proof-of-concept exploit is now publicly available, significantly increasing the risk for unpatched websites. WordPress has responded by initiating forced updates for affected versions, aiming to mitigate the widespread threat.

The digital landscape of website management has been jolted by the discovery of a severe security flaw within the core of WordPress, the world’s most popular content management system. This vulnerability, now known as wp2shell, allows malicious actors to execute arbitrary code on a WordPress site through a single, unauthenticated HTTP request. Critically, the flaw resides in the core software itself, meaning that even a freshly installed WordPress site, devoid of any third-party plugins, is susceptible to attack. The vulnerability impacted all installations of WordPress versions 6.9 and 7.0 prior to the release of patched versions, a situation that WordPress has addressed by enabling forced updates through its auto-update system.

The Anatomy of wp2shell: A Chained Exploitation

The wp2shell vulnerability is not a singular flaw but rather a potent combination of two distinct security weaknesses, each now carrying its own Common Vulnerabilities and Exposures (CVE) identifier.

• CVE-2026-63030: REST API Batch-Route Confusion: This vulnerability was discovered by Adam Kues, a researcher at Assetnote, the attack surface management division of Searchlight Cyber. Kues reported the bug through WordPress’s official HackerOne bug bounty program. The issue lies in the handling of batch requests within the WordPress REST API. Specifically, an error in processing a sub-request within a batch operation can cause an internal miscalculation, leading to a misdirection of requests. This confusion allows an attacker to bypass security checks and route their malicious input to unintended handlers.

• CVE-2026-60137: SQL Injection in WordPress Core: This vulnerability was reported independently by multiple security researchers, including TF1T, dtro, and haongo. It represents a classic SQL injection flaw within the WordPress core’s database query mechanisms. When improperly handled, user-supplied input can be manipulated to alter the intended SQL query, granting attackers unauthorized access to, or manipulation of, the underlying database.

When chained together, these two vulnerabilities create a critical pathway for pre-authentication remote code execution (RCE). An anonymous attacker can leverage the REST API batch-route confusion to inject malicious data into a vulnerable SQL query, ultimately leading to the execution of arbitrary code on the compromised server.

Timeline of Discovery and Disclosure

The timeline leading up to the public disclosure and patching of wp2shell is crucial for understanding the evolving threat landscape:

• Early 2026: The initial vulnerability within the REST API batch-route handling is discovered by Adam Kues. Simultaneously, or shortly thereafter, the SQL injection flaw is identified by other independent researchers.
• Undisclosed Date Prior to July 2026: Vulnerabilities are reported to WordPress through its official channels, likely HackerOne for the batch-route issue and potentially other security contacts for the SQL injection. WordPress begins its internal investigation and development of patches.
• July 12, 2026 (Friday): WordPress releases patched versions of its software: WordPress 6.9.5 and WordPress 7.0.2. These releases incorporate fixes for both identified vulnerabilities. Crucially, WordPress activates its "forced updates" mechanism, automatically applying these patches to a significant portion of its user base.
• July 12, 2026 onwards: Following the release of the patches, the full technical details of the exploitation mechanism begin to surface. Searchlight Cyber publishes a write-up under the moniker "wp2shell," detailing the attack’s pre-conditionless nature.
• July 15, 2026 (Approximate): A working proof-of-concept (PoC) exploit for wp2shell becomes publicly available on platforms like GitHub. This development dramatically lowers the barrier to entry for potential attackers.
• July 18, 2026: The two vulnerabilities are officially assigned CVE IDs: CVE-2026-63030 for the REST API batch-route confusion and CVE-2026-60137 for the SQL injection. This allows security scanners and organizations to more effectively identify and track the threat. Security firms like Rapid7 announce the inclusion of authenticated checks for these vulnerabilities in their scanning tools.

The Scope of Exposure

The impact of wp2shell is potentially vast, given WordPress’s dominant market share in the website development world. Estimates suggest that over 500 million websites utilize WordPress. However, the specific attack vector of wp2shell has a more refined range of affected versions.

The SQL injection vulnerability (CVE-2026-60137) has a deeper historical reach, impacting WordPress versions as far back as 6.8. This means that a significant number of older, potentially unpatched sites, could be vulnerable to database compromise.

The critical remote code execution chain, however, relies on the combination of both vulnerabilities. The batch-route confusion (CVE-2026-63030) was introduced in WordPress version 6.9, which was released on December 2, 2025. Therefore, only sites running version 6.9 and above are susceptible to the full RCE exploit. This narrows the direct RCE exposure to websites running relatively recent versions of WordPress, generally less than eight months old at the time of disclosure.

WordPress’s decision to implement forced updates is a critical measure to mitigate this threat. While the exact number of sites that have received the patch automatically remains undisclosed, the move aims to rapidly close the window of opportunity for attackers. However, the effectiveness of forced updates depends on server configurations and whether users have explicitly disabled auto-updates, a practice that can leave sites vulnerable.

Technical Deep Dive: Exploiting the Flaws

The wp2shell exploit chain involves two key components working in tandem:

1. The SQL Injection Vector: The SQL injection vulnerability resides within the WP_Query class, specifically in the handling of the author__not_in parameter. When this parameter is expected to receive an array of author IDs but instead receives a malformed string, the internal validation checks are bypassed. This allows the raw, attacker-controlled string to be directly incorporated into the SQL query, leading to unintended database manipulation.

2. The Unauthenticated Access Mechanism: The REST API batch endpoint (/wp-json/batch/v1) is designed to process multiple API requests in a single HTTP call. This feature, introduced in WordPress 5.6 in 2020, utilizes parallel arrays to track individual sub-requests. The batch-route confusion vulnerability (CVE-2026-63030), present in versions 6.9 and later, exploits an error condition within this processing. When an error occurs during the execution of one sub-request, it can cause the tracking arrays to fall out of sync by a single element. This misalignment allows a subsequent, malicious sub-request to be processed by an unintended handler, effectively bypassing the endpoint’s intended security controls and allowing an attacker to reach the vulnerable WP_Query parameter without authentication.

By combining these two flaws, an attacker can craft a single HTTP request to the batch endpoint. This request triggers the batch-route confusion, which then directs the attacker’s input to the vulnerable author__not_in parameter. The malformed input bypasses validation, injects malicious SQL code, and ultimately leads to remote code execution on the affected WordPress site.

Scoring and Severity: A Nuanced Perspective

The severity of wp2shell has been a subject of detailed analysis, with differing scores assigned by WordPress and the CVE system.

WordPress’s own security advisory rates the RCE chain as "Critical." This designation reflects the devastating impact of arbitrary code execution on a website.

However, the CVE record for the SQL injection component (CVE-2026-60137) assigns a CVSS score of 7.5, categorizing it as "High." This score primarily focuses on the direct impact on data access, rather than the full spectrum of integrity and availability loss that code execution can entail.

The discrepancy highlights the nuanced nature of vulnerability scoring. The SQL injection’s direct access to the database is highly impactful, while the batch-route confusion, on its own, might be perceived more as a parsing or access control flaw. Security professionals are advised to track both CVEs individually, understanding that the "Critical" label often refers to the combined RCE capability, while the individual components have their own risk profiles.

The Persistent Object Cache Condition

A crucial mitigating factor, albeit a conditional one, has been identified by Cloudflare, which has released Web Application Firewall (WAF) rules to counter the attack. The full remote code execution path of wp2shell functions only when a website is not running a persistent object cache.

A default WordPress installation typically does not employ a persistent object cache. This means that a significant portion of sites, particularly those that have not undergone custom optimization, remain exposed to the RCE chain. Websites that utilize caching mechanisms like Redis or Memcached as a persistent object cache may be shielded from this specific RCE pathway. However, this is a secondary effect and does not negate the risk posed by the underlying SQL injection vulnerability, which can still be exploited independently.

Industry Reactions and Broader Implications

The discovery of wp2shell has sent ripples through the cybersecurity community. The ease of exploitation and the critical nature of the flaw have raised concerns about the ongoing security of the vast WordPress ecosystem.

• Searchlight Cyber’s Role: Assetnote, through Searchlight Cyber, has played a pivotal role in uncovering and disclosing this vulnerability. Their research highlights the importance of dedicated attack surface management and proactive security research in identifying complex, chained exploits. While Searchlight has withheld their full technical write-up, their identification of the batch-route bug and their partnership with WordPress have been instrumental in driving the patching process.

• WordPress’s Response: The swift release of patched versions and the implementation of forced updates demonstrate WordPress’s commitment to user security. This aggressive approach is a necessary response to the high-impact nature of the vulnerability and the rapid dissemination of exploit information. However, the reliance on auto-updates, even forced ones, underscores the importance of users maintaining awareness and ensuring their sites are configured for security.

• Security Firm Readiness: As CVE IDs have been assigned, security vendors are rapidly integrating detection and mitigation capabilities. Rapid7 has announced authenticated checks for its InsightVM and Nexpose platforms, indicating that enterprise-level security solutions are prepared to identify affected systems. The absence of wp2shell from CISA’s Known Exploited Vulnerabilities (KEV) catalog as of July 18, 2026, suggests that confirmed exploitation in the wild has not yet been widely reported. However, this should not be interpreted as a lack of immediate threat, especially given the public availability of proof-of-concept exploits.

• The Evolving Threat Landscape: The wp2shell incident serves as a stark reminder of the persistent threat posed by vulnerabilities in widely used software. The history of WordPress security includes numerous instances where flaws, even in core software, have been exploited by malicious actors. The recent past has seen campaigns like WP-SHELLSTORM, where a caching plugin flaw allowed access to thousands of sites. wp2shell, by contrast, affects the core software and can operate on default configurations, presenting a potentially broader and more immediate danger.

Mitigation Strategies for Users

For WordPress site owners who cannot immediately update or wish to implement additional layers of defense, several mitigation strategies are available. These are generally considered stopgap measures until a full update can be applied and may potentially interfere with legitimate site functionality:

• Restricting Access to the Batch Endpoint: The most direct mitigation involves preventing anonymous access to the /wp-json/batch/v1 endpoint. This can be achieved through various methods:

  • Web Server Configuration (e.g., Apache, Nginx): Modifying server configuration files to block requests to this specific endpoint from unauthenticated users. This is often the most effective method but requires server-level access and technical expertise.
  • Web Application Firewalls (WAFs): Implementing WAF rules, such as those provided by Cloudflare or other security providers, to detect and block malicious requests targeting the batch endpoint.
  • Security Plugins: Certain advanced security plugins may offer options to disable or restrict access to specific REST API endpoints.

• Disabling the REST API (with Caution): In some extreme cases, site administrators might consider disabling the entire WordPress REST API. However, this is a drastic measure that can break many legitimate plugins and themes that rely on the API for their functionality, including the WordPress Customizer and Gutenberg editor. This is generally not recommended unless absolutely necessary and with a full understanding of the consequences.

The Race Against Exploitation

The disclosure of wp2shell has ignited a race between security professionals and malicious actors. WordPress has acted decisively by pushing out patches and enabling forced updates, a testament to the severity of the threat. However, the open-source nature of WordPress means that the patch itself serves as a map for those seeking to exploit the vulnerability.

The publication of the mechanism and the subsequent release of a working proof-of-concept exploit mean that the window of opportunity for attackers is wide open. The true measure of success in mitigating this threat will be reflected in the adoption rate of the patches versus the volume of malicious traffic attempting to exploit the vulnerability. Website owners are strongly urged to verify their WordPress version and ensure that they are running the latest patched releases to safeguard their digital assets. The ongoing battle between defenders and attackers in the WordPress ecosystem continues, underscoring the perpetual need for vigilance and prompt security updates.