Critical WordPress Core Vulnerability WP2Shell Enables Unauthenticated Remote Code Execution Across Millions of Sites

The global cybersecurity landscape faced a significant disruption this week following the disclosure of a critical vulnerability chain in WordPress core, dubbed wp2shell, which allows unauthenticated attackers to execute arbitrary code on affected websites. Discovered by security researchers and disclosed through formal channels, the flaw resides within the fundamental architecture of the WordPress content management system (CMS), meaning even a baseline installation with no third-party plugins or themes is susceptible to compromise. The vulnerability primarily affects WordPress versions 6.9 and 7.0, a range that encompasses a substantial portion of the modern web. In response to the escalating threat, the WordPress security team has taken the rare step of initiating forced updates to versions 6.9.5 and 7.0.2 to mitigate the risk of mass exploitation.

The wp2shell threat is composed of two distinct vulnerabilities that, when chained together, provide a pathway for an anonymous HTTP request to gain full control over a target server. The first component, identified as CVE-2026-63030, involves a logic error in the WordPress REST API’s batch-processing route. The second component, CVE-2026-60137, is a sophisticated SQL injection vulnerability located within the WordPress core’s query handling logic. While each bug presents a security risk in isolation, their combination represents a "perfect storm" for web administrators, bypassing standard authentication requirements and landing directly into the application’s execution layer.

Technical Mechanism of the wp2shell Chain

The technical complexity of wp2shell lies in how it manipulates the WordPress REST API to reach vulnerable internal functions. Since the introduction of the REST API batch framework in version 5.6, WordPress has allowed developers to perform multiple API requests within a single HTTP call via the /wp-json/batch/v1 route. This system was designed to improve efficiency by reducing the overhead of multiple network requests. However, researchers discovered a "batch-route confusion" flaw in version 6.9.

The vulnerability stems from how the batch controller tracks sub-requests using parallel arrays. If a specific type of error occurs during one of the sub-requests, the indexing of these arrays can fall out of synchronization. This misalignment allows an attacker to craft a nested request where the security checks intended for one endpoint are applied to a different, more sensitive handler. By navigating this confusion, an unauthenticated user can bypass the allow-list of the batch endpoint and pass malicious input to internal WordPress functions that are typically protected by authentication layers.

Once the authentication barrier is bypassed via CVE-2026-63030, the attacker targets the second vulnerability, CVE-2026-60137. This SQL injection exists within the WP_Query class, specifically the author__not_in parameter. Under normal circumstances, WordPress expects this parameter to receive an array of integers. However, the core logic fails to properly validate the input if a string is provided instead. By supplying a carefully crafted string, an attacker can skip the array-sanitization check, allowing raw SQL commands to be injected directly into the database query. In the context of the wp2shell chain, this SQL injection is used to escalate privileges or modify the database in a manner that leads to Remote Code Execution (RCE).

Chronology of Discovery and Disclosure

The discovery of the wp2shell chain involved multiple independent research teams, highlighting the widespread scrutiny of the WordPress core codebase. Adam Kues, a researcher at Assetnote—the attack surface management division of Searchlight Cyber—identified the batch-route confusion and reported it through the WordPress HackerOne bug bounty program. Concurrently, the SQL injection vulnerability was reported by a group of researchers including TF1T, dtro, and haongo.

The timeline of the event reflects a rapid transition from private disclosure to public availability of exploit code:

• December 2, 2025: WordPress 6.9 is released, introducing the logic that would eventually be identified as the batch-route confusion bug.
• Early 2026: Researchers identify the flaws and begin the responsible disclosure process via HackerOne.
• July 12, 2026: WordPress developers finalize patches for the vulnerabilities.
• July 17, 2026: WordPress releases versions 6.9.5 and 7.0.2. The "forced update" mechanism is triggered to protect sites that have not manually updated.
• July 18, 2026: Technical details of the exploit mechanism are published online. Shortly thereafter, a functional proof-of-concept (PoC) exploit is uploaded to GitHub, significantly increasing the risk of widespread automated attacks.
• July 20, 2026: Major security scanning vendors, including Rapid7, schedule the release of authenticated checks for vulnerability management platforms.

The Forced Update Strategy and Version Range

One of the most notable aspects of the WordPress response is the use of forced updates. While WordPress has utilized auto-updates for minor security releases for years, the "forced" nature of this push suggests a high level of urgency. The security team has not explicitly confirmed whether these updates will override settings on sites where administrators have explicitly disabled automatic updates. This has led to a debate within the technical community regarding the balance between user autonomy and the collective security of the internet.

The vulnerability’s reach is determined by the version of WordPress in use. The SQL injection (CVE-2026-60137) is present in versions as far back as 6.8. However, the batch-route confusion (CVE-2026-63030), which is required to trigger the injection without authentication, only exists in versions 6.9 and 7.0. Consequently, while a version 6.8 site contains a vulnerability, it is not susceptible to the unauthenticated RCE chain described in the wp2shell write-up. This distinction is why WordPress released version 6.8.6, which patches the SQL injection alone, while the 6.9 and 7.0 branches received more comprehensive fixes.

Discrepancies in Severity Scoring

An unusual point of contention in the wp2shell disclosure is the variance in Common Vulnerability Scoring System (CVSS) ratings. WordPress’s internal advisory classifies the RCE chain as "Critical." However, the official CVE record assigned a score of 7.5, which falls into the "High" category. This lower score is attributed to the fact that the impact metrics primarily credit data access rather than full integrity or availability loss.

In contrast, the SQL injection component (CVE-2026-60137) has received scores exceeding 9.1, placing it firmly in the "Critical" range. Security analysts suggest that this scoring paradox occurs because the batch-route confusion is viewed as a parsing or routing flaw, whereas the SQL injection is recognized for its direct and devastating reach into the database. Experts advise organizations to focus on the "Critical" label of the overall chain rather than the individual scores of the components, as the functional result is complete server compromise.

Mitigation and Environmental Factors

For administrators unable to apply the official patches immediately, certain environmental factors may provide temporary, incidental protection. Research from Cloudflare indicates that the RCE path is generally only exploitable on sites that do not utilize a persistent object cache. A standard, default WordPress installation does not include such a cache, leaving the majority of users exposed. However, sites using Redis or Memcached as a persistent object cache may find that the specific memory-handling behavior of these systems disrupts the batch-route confusion mechanism.

Nevertheless, security experts warn that relying on an object cache is a side effect of system architecture rather than a true security fix. It does not address the underlying SQL injection, and attackers may find alternative ways to trigger the flaw. Searchlight Cyber has recommended several stopgap measures for those who cannot update:

1. Disabling the REST API batch endpoint entirely via code snippets or security plugins.
2. Implementing Web Application Firewall (WAF) rules to block suspicious requests to /wp-json/batch/v1.
3. Restricting access to the REST API to known, authorized IP addresses.

Broader Impact and Industry Context

The potential for mass exploitation of wp2shell is underscored by the sheer scale of the WordPress ecosystem. With over 500 million websites running on the platform, even a vulnerability limited to versions released within the last eight months affects millions of targets. The "industrialization" of WordPress exploitation is a well-documented phenomenon. Earlier in 2026, a leak from a threat actor group known as WP-SHELLSTORM revealed that a single vulnerability in a popular caching plugin allowed them to compromise over 17,000 sites.

The wp2shell vulnerability is considered more dangerous than previous plugin-based flaws because it resides in the core software and works on default settings. This eliminates the need for attackers to scan for specific configurations or installed add-ons; every site running an unpatched version of 6.9 or 7.0 is a potential target.

As of July 18, 2026, there have been no confirmed reports of mass exploitation in the wild, and the vulnerability has not yet appeared on the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog. However, with the public release of the PoC on GitHub, the window for defensive action is closing rapidly. The speed at which administrators apply the patch—or at which the forced update propagates—will determine whether wp2shell becomes one of the most significant breach events in recent history. The security community continues to monitor global scan traffic for increased activity directed at the REST API batch routes, signaling the start of the exploitation phase.