WordPress Core Vulnerabilities: A Double-Edged Sword Threatens Millions of Websites

Updated July 18, 2026: The two critical vulnerabilities discovered in the core of WordPress, collectively dubbed "wp2shell," have now been assigned CVE (Common Vulnerabilities and Exposures) identifiers, bringing a heightened sense of urgency to the ongoing cybersecurity landscape. The full technical mechanism of exploitation has been published, a specific condition involving persistent object caching has been identified, and a functional proof-of-concept is now publicly available. This revised report encompasses these critical developments, reflecting the evolving nature of the threat.

An anonymous HTTP request can now be leveraged to execute arbitrary code on a WordPress site, a vulnerability that affects the very foundation of the popular content management system. The flaw resides within the WordPress core itself, meaning that even a clean installation devoid of any third-party plugins is susceptible to exploitation. Until Friday, July 17, 2026, all WordPress sites running versions 6.9 and 7.0 were considered at risk. However, WordPress swiftly addressed the issue by releasing critical patches, version 6.9.5 and 7.0.2 respectively, and initiating its "forced updates" mechanism through its auto-update system to ensure wider adoption of the fixes.

The "wp2shell" vulnerability is not a singular bug but rather a combination of two distinct security weaknesses, both of which have now been formally recognized with CVE IDs. The first, CVE-2026-63030, stems from a confusion within the REST API’s batch routing functionality. The second, CVE-2026-60137, is a SQL injection vulnerability embedded within the WordPress core. When chained together, these two flaws create a pathway for an unauthenticated attacker to achieve remote code execution (RCE) on a vulnerable WordPress installation.

The timeline of events has accelerated rapidly since the initial discovery. Following the patching by WordPress, the complete technical details of the exploitation chain have been disseminated, and a working proof-of-concept has been made available on the popular code-sharing platform GitHub. This public release significantly amplifies the risk, as it provides malicious actors with a ready-made tool to exploit the vulnerabilities.

The discovery of the batch-route bug is credited to Adam Kues of Assetnote, the attack surface management division of Searchlight Cyber. Kues responsibly disclosed the vulnerability through WordPress’s established HackerOne program, a platform designed for secure vulnerability reporting.

A detailed write-up, published under the moniker "wp2shell," underscores the severity of the attack, stating that it possesses "no preconditions and can be exploited by an anonymous user." The SQL injection component, a critical element in achieving full code execution, was independently reported by a trio of security researchers: TF1T, dtro, and haongo.

Searchlight Cyber, while refraining from releasing its own in-depth technical analysis at this juncture, has directed website owners to a dedicated checker at wp2shell.com to assess their exposure. This measured approach, however, has been largely overshadowed by the public availability of the patch and subsequent analysis by other researchers who have meticulously dissected the code changes.

The differing version ranges affected by each individual bug are a crucial factor in understanding the precise scope of the threat. The SQL injection vulnerability has a longer reach, impacting WordPress versions dating back to 6.8. Conversely, the batch-route confusion, which transforms a bounded injection into unauthenticated RCE, is specific to versions 6.9 and later. This distinction leads to a bifurcated risk profile:

• WordPress versions 6.8.0 through 6.8.5: These versions are susceptible to the SQL injection vulnerability (CVE-2026-60137) but not the full RCE chain, as the batch-route confusion is absent. While still a significant security concern, the potential for complete system compromise is mitigated.
• WordPress versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1: These versions are vulnerable to both the SQL injection and the batch-route confusion, making them fully exploitable for remote code execution.

The latest stable release, WordPress 7.1 beta2, is confirmed to incorporate fixes for both vulnerabilities. The decision to patch versions 6.8.x with a fix for the SQL injection alone reflects the understanding that the RCE chain is not possible on these older installations.

A significant point of concern for website administrators is the extent to which WordPress’s forced update mechanism will reach sites that have had auto-updates intentionally disabled. WordPress has not yet provided explicit confirmation on this matter. Therefore, it is imperative for all users to verify their current WordPress version directly rather than assuming the update has been successfully applied.

The sheer scale of the WordPress ecosystem, with an estimated 500 million websites running on the platform, presents a formidable attack surface. However, it is important to note that this figure represents the total install base, not the number of directly exposed sites. The critical RCE chain, dependent on the batch-route confusion, is only present in versions 6.9 and later. WordPress version 6.9 was initially released on December 2, 2025, meaning that any site vulnerable to the full RCE path is running a release that is less than eight months old. The exact number of sites affected by this specific RCE path remains undisclosed in any official advisories.

The technical intricacies of the exploit chain reveal subtle yet critical flaws. The SQL injection originates within the WP_Query class, specifically within the author__not_in parameter. When this parameter is provided with a string instead of the expected array, a crucial validation check is bypassed, allowing the raw input value to be directly incorporated into the database query.

The challenge of reaching this vulnerable parameter without authentication is overcome by the batch endpoint’s functionality. WordPress’s /wp-json/batch/v1 route is designed to process multiple sub-requests within a single HTTP call, managing these requests using two parallel arrays. An error occurring within one of these sub-requests can cause the arrays to fall out of synchronization by a single position. This desynchronization can lead to a situation where a subsequent request is processed by an unintended handler.

When nested, this confusion can bypass the endpoint’s access control mechanisms, allowing an attacker’s input to be directed to the vulnerable query without requiring any form of authentication. The batch endpoint itself has been a feature of WordPress since version 5.6, released in November 2020. However, the specific confusion that enables its abuse is a new development introduced in version 6.9.

The security scoring of these vulnerabilities warrants careful examination. WordPress’s own security advisory rates the RCE chain as "Critical." However, its CVE record assigns a CVSS (Common Vulnerability Scoring System) score of 7.5, categorized as "High," with impact metrics primarily focusing on data access rather than the integrity or availability losses typically associated with code execution. The SQL injection vulnerability, on its own, receives a higher score, exceeding 9.1, also classified as "Critical." This discrepancy highlights a potential underestimation of the broader impact of the RCE. Security professionals are advised to track both CVEs independently, rather than solely relying on the "critical RCE" label.

A specific condition has been identified that narrows the potential blast radius of the code-execution path. According to Cloudflare, which has released Web Application Firewall (WAF) rules to mitigate the threat, the code execution is only achievable when a WordPress site is not running a persistent object cache. A default WordPress installation typically does not employ such caching mechanisms, leaving sites configured in their default state exposed to this specific RCE vector. While sites utilizing Redis or Memcached as persistent object caches might be protected from this particular RCE path, this serves as a side effect rather than a direct fix and does not offer protection against the standalone SQL injection vulnerability.

With CVE IDs now formally assigned, security scanning tools are rapidly incorporating detection capabilities. Rapid7 has indicated that authenticated checks for its InsightVM and Nexpose platforms will be available by July 20, 2026. As of July 18, 2026, the vulnerability has not been listed on the CISA (Cybersecurity and Infrastructure Security Agency) Known Exploited Vulnerabilities (KEV) catalog, which typically requires confirmed instances of active exploitation. No public reports of exploitation have been officially confirmed to date, offering a thin layer of comfort.

The history of WordPress security incidents demonstrates a pattern of widespread exploitation. Prior to a server leak in June 2026, a single vulnerability in a caching plugin alone was leveraged by the "WP-SHELLSTORM" group to compromise over 17,000 websites. This attack utilized a bug that was already public, already patched, and only affected a non-default configuration. The current "wp2shell" vulnerabilities, in contrast, are public, patched, and the RCE path is exploitable on default configurations, amplifying the potential for widespread damage.

Mitigating the Threat: Strategies for Unpatched Systems

For website administrators unable to immediately update their WordPress installations, Searchlight offers several mitigation strategies. These measures primarily focus on restricting anonymous access to the batch endpoint. It is crucial to understand that these are temporary stopgap solutions and may potentially disrupt legitimate integrations and functionalities.

• Web Application Firewall (WAF) Rules: Implementing WAF rules that specifically block requests to the /wp-json/batch/v1 endpoint from unauthenticated users can serve as an effective deterrent.
• Server-Level Access Control: At the server level, administrators can configure access control lists (ACLs) or use .htaccess files to deny access to the batch endpoint for anonymous visitors.
• Plugin-Specific Restrictions: If a specific plugin is known to utilize the batch endpoint legitimately, administrators can attempt to create more granular rules to allow its functionality while blocking other unauthorized access.

The open-source nature of WordPress core means that its source code is publicly available. The release notes for the patches clearly identify the modified files, providing a roadmap to the vulnerabilities. While Searchlight Cyber initially withheld its full technical write-up, the rapid analysis by other security researchers led to the swift publication of the exploitation mechanism and the public release of an exploit on GitHub. This sequence of events underscores the inherent challenge in disclosing vulnerabilities in open-source software: the act of providing a fix often simultaneously provides the blueprint for its exploitation.

The primary lever available to WordPress and its administrators is the speed at which patches are deployed and adopted. WordPress’s decision to implement forced updates for vulnerable versions represents a decisive move to accelerate this process. The success of this strategy will ultimately be determined by the interplay between the speed of patch adoption and the rate at which malicious actors leverage the publicly available exploit.

The coming days and weeks will be critical. WordPress’s version statistics will offer insight into the number of sites that have successfully applied the patch. Concurrently, monitoring web server logs for traffic targeting the /batch/v1 endpoint will reveal the extent of active exploitation attempts. The balance between these two trends will dictate the ultimate narrative surrounding this critical security incident.

The cybersecurity community is keenly observing the fallout from these vulnerabilities. While official advisories and security tools are catching up, the rapid public availability of the exploit means that the threat landscape is dynamic and potentially volatile. Proactive measures, even temporary ones, are essential for safeguarding WordPress websites against this sophisticated attack.