WordPress Core Vulnerabilities Allow Anonymous Code Execution via Chained Exploits

Updated July 18, 2026: The two critical vulnerabilities discovered in WordPress core, collectively dubbed "wp2shell," have now been assigned CVE (Common Vulnerabilities and Exposures) identifiers, with the full exploitation mechanism publicly detailed. A persistent object cache condition has also been identified as a factor influencing exploitability, and a working proof-of-concept is now available. This updated report reflects these significant developments.

An anonymous HTTP request can now lead to arbitrary code execution on a WordPress site, a severe security flaw impacting core functionality. This vulnerability affects all installations of WordPress versions 6.9 and 7.0. WordPress addressed this issue by releasing patched versions, 6.9.5 and 7.0.2, on Friday, July 17, 2026, enabling forced updates through its auto-update system to expedite the patching process for a vast number of websites.

The "wp2shell" exploit is not a singular bug but a combination of two distinct vulnerabilities. The first, identified as CVE-2026-63030, is a confusion within the REST API’s batch routing functionality. The second, CVE-2026-60137, is a SQL injection flaw embedded directly within WordPress core. When chained together, these vulnerabilities allow an unauthenticated attacker to execute arbitrary code on a vulnerable WordPress server.

Since Friday, the complete technical details of how these vulnerabilities can be exploited have been published, and a functional proof-of-concept exploit has been made available on GitHub, significantly increasing the immediate threat to websites that have not yet been updated.

Discovery and Disclosure

The batch-route confusion vulnerability (CVE-2026-63030) was discovered by Adam Kues of Assetnote, the attack surface management division of Searchlight Cyber. Kues responsibly reported the finding through WordPress’s HackerOne bug bounty program. The technical write-up, published under the moniker "wp2shell," emphasizes that the attack requires "no preconditions and can be exploited by an anonymous user." The SQL injection vulnerability (CVE-2026-60137) was reported independently by multiple researchers: TF1T, dtro, and haongo.

Searchlight Cyber is currently withholding its in-depth technical analysis, citing the ongoing risk to unpatched systems. However, they have provided a checker tool at wp2shell.com to help website owners determine their vulnerability status. The company’s cautious approach is understandable, but the disclosure of the patch itself has effectively provided other researchers with the necessary information to understand and replicate the exploit.

Vulnerability Scope and Timeline

The two vulnerabilities do not affect the same version ranges, which is a critical factor in determining the specific exposure of different WordPress installations. The SQL injection vulnerability dates back to WordPress version 6.8. However, the batch-route confusion, which is the crucial component that elevates a bounded injection into unauthenticated remote code execution (RCE), was introduced in WordPress version 6.9.

This distinction means that websites running versions prior to 6.9 are susceptible to the SQL injection but not the full RCE chain. For example, a WordPress 6.8 site is not exploitable for RCE through this specific attack chain, which explains why the 6.8.6 patch specifically addresses the SQL injection component without the RCE implications.

WordPress version 7.1 beta2 includes fixes for both vulnerabilities. The forced update mechanism initiated by WordPress is designed to reach sites that have auto-updates enabled. However, it remains unclear whether this forced push extends to sites where users have explicitly disabled automatic updates. Therefore, website administrators are strongly advised to verify their current WordPress version rather than assuming the patch has been applied automatically.

Estimates suggest that over 500 million websites utilize WordPress. However, this figure represents the total install base, not the number of sites directly exposed to the RCE chain. The RCE exploit path is only present in versions 6.9 and later. WordPress 6.9 was released on December 2, 2025. Consequently, any site vulnerable to the code execution path is running a version released within the last eight months. As of the latest reports, there is no official advisory detailing the exact number of sites running these vulnerable versions.

Technical Breakdown of the Exploit Chain

The "wp2shell" exploit chain relies on two specific misconfigurations within WordPress core.

1. SQL Injection in WP_Query: The SQL injection vulnerability resides within the WP_Query class, specifically in the author__not_in parameter. When this parameter is supplied with a string instead of the expected array, the validation check that anticipates an array is bypassed. This allows the raw, potentially malicious, string input to be directly incorporated into the database query, leading to SQL injection.

2. REST API Batch Route Confusion: The mechanism for reaching the vulnerable author__not_in parameter without requiring authentication is facilitated by the WordPress REST API’s batch endpoint. Located at /wp-json/batch/v1, this route allows multiple sub-requests to be processed within a single HTTP call. The system manages these requests using two parallel arrays. However, an error occurring in one sub-request can disrupt the synchronization of these arrays, causing subsequent requests to be handled by an unintended handler.

When these two vulnerabilities are chained, the confusion within the batch endpoint allows an attacker’s input, intended for the batch processing, to bypass the endpoint’s allow-list and be directed to the vulnerable WP_Query parameter. This results in unauthenticated access to the SQL injection vulnerability. The batch endpoint functionality has been part of WordPress core since version 5.6, released in November 2020. However, the specific confusion that enables this exploit is a new flaw introduced in version 6.9.

Vulnerability Scoring and Implications

The severity of these vulnerabilities is reflected in their official scoring, though there are notable discrepancies. WordPress’s own security advisory rates the chained RCE vulnerability as "Critical." However, its CVE record assigns a CVSS score of 7.5, categorized as "High." The impact metrics for this score primarily credit data access, overlooking the potential for integrity and availability loss that typically accompanies code execution.

The SQL injection vulnerability, when considered independently, receives higher scores, exceeding 9.1, also classifying it as "Critical." This discrepancy highlights a crucial point for security professionals: the label "Critical RCE" might obscure the fact that the underlying SQL injection has a broader reach and potentially more severe direct impact on database integrity. Therefore, it is imperative to track both CVEs individually, rather than relying solely on the overarching label assigned to the RCE chain.

A significant mitigating factor identified by Cloudflare, which has released Web Application Firewall (WAF) rules to counter these threats, is the presence of a persistent object cache. The code execution path is reportedly only functional when a site is not utilizing a persistent object cache. Default WordPress installations typically do not employ such caching mechanisms, meaning a standard, out-of-the-box WordPress site remains exposed to this specific RCE vector. While sites employing Redis or Memcached as persistent object caches might be shielded from this particular RCE path, this is a circumstantial defense and does not address the underlying SQL injection vulnerability.

Industry Response and Remediation

With CVE IDs now assigned, security scanners are beginning to incorporate detection for these vulnerabilities. Rapid7 has announced that authenticated checks for InsightVM and Nexpose will be available starting July 20, 2026. As of July 18, 2026, the vulnerability has not been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog, which typically requires confirmed exploitation in the wild. No exploitation of these specific vulnerabilities has been publicly reported to date. However, the availability of a public proof-of-concept means that this period of relative quiet could be short-lived.

The history of WordPress security incidents underscores the rapid exploitation of publicly disclosed vulnerabilities. Prior to its server leak in June 2026, a flaw in a caching plugin was exploited by the "WP-SHELLSTORM" group to compromise over 17,000 websites. This occurred despite the bug being public, already patched, and only exploitable under a non-default configuration. The current "wp2shell" vulnerabilities are similar in that they are public and patched, but critically, they work on default configurations, increasing their potential impact.

Mitigation Strategies for Unpatched Sites

For website administrators unable to update immediately, Searchlight Cyber has outlined several mitigation strategies. These are considered temporary measures and aim to prevent anonymous access to the batch endpoint, thereby disrupting the exploit chain. However, it is important to note that these stopgap solutions may interfere with legitimate integrations and should be implemented with caution.

• Blocking the Batch Endpoint: Disabling or blocking access to the /wp-json/batch/v1 endpoint entirely can prevent the exploit. This can be achieved through web server configurations (e.g., Apache’s .htaccess or Nginx’s configuration files) or by using a Web Application Firewall (WAF).
• Rate Limiting Anonymous Access: Implementing strict rate limiting for anonymous requests to the batch endpoint can deter automated attacks and make exploitation more difficult.
• Disabling WP_DEBUG: While not a direct fix, ensuring that WP_DEBUG is set to false in production environments is a standard security best practice that can sometimes hinder exploit attempts by preventing the leakage of detailed error messages.

The open-source nature of WordPress core means that patches are publicly available. The release notes for the patched versions name the specific files that were modified. This transparency, while beneficial for community development, also means that understanding and replicating the fix is relatively straightforward for malicious actors. Searchlight Cyber’s decision to delay its full technical write-up was an attempt to slow down the inevitable wave of exploitation. However, within 24 hours of the patch’s release, other researchers had deciphered the changes, published the exploitation mechanism, and released a proof-of-concept exploit on GitHub.

This situation highlights a recurring challenge in open-source software security: the inherent tension between rapid patching and the potential for immediate exploitation once a fix is known. The only effective lever remaining for WordPress was to accelerate the deployment of the patch through its forced auto-update system, which was implemented on Friday.

The ongoing race is now between the speed at which the patch reaches websites and the speed at which attackers scan for and exploit vulnerable systems. WordPress’s version statistics will indicate the adoption rate of the patch, while network traffic analysis targeting the /batch/v1 endpoint will reveal the extent of attacker reconnaissance. The relative steepness of these two curves will ultimately determine the long-term impact and legacy of the "wp2shell" vulnerabilities.

Follow us on Google News, Twitter, and LinkedIn for more exclusive content and breaking cybersecurity news.