WordPress Core Vulnerability: Pre-Authentication Remote Code Execution Threatens Millions of Sites

An anonymous HTTP request can execute arbitrary code on a WordPress site, a critical vulnerability discovered in the core software that affects even a bare installation without any plugins. This significant security flaw, designated as "wp2shell" by its discoverer, put an estimated 500 million websites powered by WordPress at risk until the platform released emergency patches. The vulnerability allowed unauthenticated attackers to gain control of websites, potentially leading to data breaches, malware distribution, and complete site compromise.

The flaw was identified and reported by Adam Kues of Assetnote, the attack surface management division of Searchlight Cyber, through WordPress’s official HackerOne bug bounty program. The detailed write-up, published under the moniker "wp2shell," underscored the severity of the issue, stating that the exploit has "no preconditions and can be exploited by an anonymous user." This means that any individual, without needing any credentials or prior access, could potentially compromise a vulnerable WordPress site.

The immediate concern for WordPress users stemmed from the widespread adoption of the platform. WordPress powers a substantial portion of the internet, estimated to be over 40% of all websites. The discovery of a vulnerability in its core code, the fundamental building blocks of the content management system, meant that a vast number of websites were exposed. This broad impact necessitates a thorough understanding of the timeline, the nature of the exploit, and the mitigation strategies available to website owners.

Timeline of the Vulnerability and Patching Efforts

The timeline of this critical vulnerability and its subsequent patching is crucial for understanding the risk landscape and the speed of response from the WordPress security team.

• Early 2026 (Specific Date Unknown): The vulnerability, later dubbed "wp2shell," is introduced into the WordPress core software through an update. While the exact version where the flaw was first introduced isn’t explicitly stated as being prior to 6.9, the affected versions clearly indicate a relatively recent introduction. The fact that it was present in a "bare install with zero plugins" suggests it was deeply embedded in the core functionality.

• Prior to July 17, 2026: Adam Kues of Assetnote/Searchlight Cyber discovers the vulnerability. The researcher responsibly discloses the flaw through WordPress’s HackerOne program, a standard procedure for security researchers to report vulnerabilities to software vendors.

• July 17, 2026: WordPress releases two critical security updates: version 6.9.5 and version 7.0.2. These updates are explicitly designed to address the pre-authentication Remote Code Execution (RCE) vulnerability. The release notes describe the flaw as a "REST API batch-route confusion and SQL injection issue leading to Remote Code Execution."

• July 17, 2026: Following WordPress’s public advisory, Searchlight Cyber publishes their technical write-up, "wp2shell," and launches a dedicated checker website (wp2shell.com) allowing website owners to test their instances for the vulnerability. They also choose to withhold full technical exploit details for a period, aiming to give defenders more time to patch before widespread exploitation.

• July 17, 2026: WordPress also releases version 7.1 beta 2, which includes the same fix. Separately, version 6.8.6 is released for the 6.8 branch, addressing a different SQL injection vulnerability reported by another security team, indicating a broader security audit and patching effort across recent WordPress versions.

• July 18, 2026: As of this date, no exploitation attempts have been publicly reported. This is attributed to the lack of a CVE (Common Vulnerabilities and Exposures) identifier and the absence of widely disseminated exploit signatures, which would typically be used by automated scanning tools and threat intelligence platforms.

  

The "Forced Updates" Mechanism

A significant aspect of WordPress’s response was the implementation of "forced updates." For sites running versions 6.9 and 7.0, WordPress automatically applied the security patches, pushing versions 6.9.5 and 7.0.2, respectively. This aggressive approach was employed due to the critical nature of the vulnerability and the potential for widespread exploitation.

However, a crucial point of uncertainty remains regarding whether these forced updates reached sites that had previously disabled the auto-update feature. WordPress’s official advisory did not explicitly confirm this, prompting a strong recommendation for website owners to manually verify their current WordPress version rather than assuming the update has been applied. This highlights the challenge of ensuring security across a diverse and globally distributed user base, where configurations can vary significantly.

The Nature of the Vulnerability: REST API Batch-Route Confusion and SQL Injection

WordPress’s release post provides a technical description of Kues’s finding: "a REST API batch-route confusion and SQL injection issue leading to Remote Code Execution." This indicates a multi-stage attack vector that leverages weaknesses in how the WordPress REST API handles batch requests and processes data, leading to a more severe outcome.

The REST API is a fundamental component of modern WordPress, allowing for programmatic interaction with the website’s data and functionality. The "batch-route" feature, introduced in WordPress 5.6 in November 2020, enables multiple API requests to be sent in a single HTTP request, improving efficiency. However, it appears that a flaw in the implementation or processing of these batch routes in versions 6.9 and 7.0 created a pathway for attackers.

The "confusion" in the batch-route handling, combined with an SQL injection vulnerability, allowed an attacker to craft malicious requests that could manipulate database queries. SQL injection is a common web security vulnerability where an attacker inserts malicious SQL code into input fields, which is then executed by the database. In this context, the injected SQL code, facilitated by the REST API flaw, could lead to the execution of arbitrary code on the server, granting the attacker full control over the website.

The affected files identified in the 7.0.2 release further illuminate the technical details:

• /wp-includes/rest-api/class-wp-rest-server.php: This file is central to the REST API’s server-side operations, likely handling the parsing and routing of incoming API requests.
• /wp-includes/class-wp-query.php: This file contains the core WordPress query class, responsible for retrieving data from the database. Modifications here could indicate how the SQL injection was facilitated.
• /wp-includes/rest-api.php: This file likely contains the core logic for the REST API’s batch functionality.

The fact that the batch endpoint itself is not new, having been available since WordPress 5.6, suggests that the vulnerability was introduced or exacerbated by changes in later versions, specifically versions 6.9 and 7.0. The precise nature of these changes, which opened the door to the exploit, has not yet been publicly detailed by WordPress or the researcher, creating a gap in understanding for those who need to analyze the codebase.

Lack of CVE and CVSS Scores

A notable absence in the reporting of this vulnerability is the lack of a CVE (Common Vulnerabilities and Exposures) identifier and a CVSS (Common Vulnerability Scoring System) score. This has several implications:

• Detection and Tracking: CVE IDs are the standard for identifying and tracking cybersecurity vulnerabilities. Without one, automated scanning tools and security inventory systems will not be able to flag this vulnerability. This makes it harder for organizations to identify their exposure and prioritize patching.
• Government Alerts: Agencies like CISA (Cybersecurity and Infrastructure Security Agency) rely on CVEs to populate their Known Exploited Vulnerabilities (KEV) catalog, which informs critical infrastructure operators about actively exploited threats. The absence of a CVE means this vulnerability cannot be officially listed by CISA, potentially reducing the urgency for some organizations to patch.
• Risk Assessment: CVSS scores provide a standardized measure of a vulnerability’s severity. The lack of a CVSS score makes it more challenging for security teams to quantitatively assess the risk and allocate resources effectively.

Consequently, website owners are advised to track this vulnerability by its version number (6.9.5 and 7.0.2 for the fixes) rather than relying on automated security tools that depend on CVE data.

Mitigation Strategies for Unpatched Sites

For website owners who cannot immediately update their WordPress installation, Searchlight Cyber has outlined several mitigation strategies. These are considered stopgap measures and are not substitutes for applying the official patches. The primary goal of these mitigations is to restrict access to the vulnerable batch endpoint.

• Web Application Firewall (WAF) Rules: Implementing custom WAF rules can block requests targeting the /wp-json/wp/v2/batch endpoint. This requires a thorough understanding of WAF configuration and may necessitate ongoing tuning to avoid blocking legitimate traffic.
• Server-Level Access Control: Configuring server access controls (e.g., through .htaccess or Nginx configuration) can restrict access to the batch endpoint. This is a more technical solution and requires server administration privileges.
• Modifying WordPress Core (Not Recommended): While technically possible, modifying WordPress core files is strongly discouraged due to the risk of breaking site functionality and making future updates more difficult.

It’s important to note that all these temporary measures carry the risk of breaking legitimate integrations or plugins that rely on the REST API batch functionality. Therefore, updating WordPress to the patched versions remains the most effective and recommended solution.

Broader Implications and the Open-Source Dilemma

The "wp2shell" vulnerability highlights a recurring challenge inherent in open-source software development, particularly for widely adopted platforms like WordPress. The very nature of open-source means that the codebase is publicly available, allowing for rapid development, community contributions, and transparency. However, it also means that once a vulnerability is discovered and a fix is released, the underlying code that caused the issue and the solution are also publicly accessible.

This creates a race against time. As WordPress core is open source, the comparison between vulnerable versions and patched versions is readily available in public release archives. Security researchers and malicious actors alike can analyze these diffs to understand the exploit. The challenge for platforms like WordPress is to ensure that their security patches are disseminated and applied by their user base faster than attackers can develop and deploy exploits based on the released fixes.

The article draws a parallel to a previous incident where a caching plugin vulnerability led to the compromise of over 17,000 sites. That bug was already public and patched, but its exploitation persisted due to delayed updates. Similarly, Searchlight Cyber’s rapid teardown of a Drupal core SQL injection vulnerability shortly after its patch was released demonstrates the speed at which security researchers can weaponize disclosed fixes.

The dilemma for open-source projects is that they cannot ship a fix without, in essence, shipping a map to the bug. The only lever they have is the speed at which their patches reach the end-user. WordPress’s decision to implement forced updates for the "wp2shell" vulnerability underscores their recognition of this critical race.

The fact that no exploitation attempts were reported by July 18th suggests that WordPress’s rapid patching and forced update strategy, combined with the researcher’s decision to withhold full technical details, may have provided a crucial window for defenders. However, the landscape of cyber threats is constantly evolving, and the absence of immediate exploitation does not guarantee future safety. As threat actors gain access to the technical details through code analysis or other means, targeting the vulnerable batch endpoint will likely become more prevalent.

The industry-wide impact of WordPress vulnerabilities is significant. Mass exploitation of WordPress sites is not uncommon. Attackers often target popular plugins and themes, but vulnerabilities in the core software represent a more fundamental and widespread threat. The sheer number of WordPress installations means that even a small percentage of unpatched sites can represent hundreds of thousands, if not millions, of potential targets for malicious actors.

The "wp2shell" vulnerability serves as a stark reminder of the ongoing need for vigilance in the cybersecurity domain. Website owners, developers, and platform providers must work collaboratively to ensure that security remains a top priority. For WordPress users, this means staying informed about security advisories, promptly applying updates, and regularly verifying their site’s security posture. The speed at which WordPress responded with forced updates indicates the severity of the threat, and the continued monitoring of traffic against the batch endpoint will be crucial in understanding when and if attackers begin to exploit this critical vulnerability. The ultimate success of security efforts will be measured not by the absence of vulnerabilities, but by the swiftness and effectiveness of their remediation across the vast WordPress ecosystem.