WordPress Core Vulnerability Allows Anonymous Remote Code Execution in Latest Releases
A critical security flaw discovered in the core of WordPress, the world’s most popular content management system, has been patched by the platform’s developers. The vulnerability, identified as a pre-authentication Remote Code Execution (RCE) bug, could have allowed anonymous attackers to execute arbitrary code on affected WordPress sites without any prior authentication. The severity of this flaw prompted WordPress to issue urgent updates, 6.9.5 and 7.0.2, on July 17, 2026, and to enable forced updates to ensure wider protection.
The discovery was made by Adam Kues of Assetnote, the attack surface management division of Searchlight Cyber. Kues reported the vulnerability through WordPress’s official HackerOne bug bounty program. The detailed technical write-up, published by Searchlight Cyber under the moniker "wp2shell," highlighted the alarming ease with which the exploit could be leveraged. The report stated that the attack has "no preconditions and can be exploited by an anonymous user," meaning an attacker did not need to log in or possess any specific credentials to compromise a site.
While Searchlight Cyber has opted to withhold the full technical details of the exploit for now, they have launched a public checker at wp2shell.com, allowing website owners to test their WordPress installations for susceptibility. This approach aims to provide immediate utility to users while preventing the rapid weaponization of the vulnerability by malicious actors before a significant portion of the web can be patched.
The patched versions, WordPress 6.9.5 and 7.0.2, address this critical RCE flaw, which impacts default installations of WordPress with no plugins. The vulnerability stems from a "REST API batch-route confusion and SQL injection issue leading to Remote Code Execution," as described in WordPress’s official release notes. The company has not specified which of the two critical and high-severity flaws mentioned in the advisories corresponds to the wp2shell vulnerability.
A timeline of events leading up to the patch reveals the rapid response required. The vulnerability was identified and reported to WordPress, triggering an accelerated development and release cycle. WordPress.org’s documentation indicates that WordPress 6.9 was released on December 2, 2025, meaning that affected sites were running a version less than eight months old. The nature of the exploit, targeting a core component accessible via an anonymous HTTP request, underscores the pervasive risk to the vast WordPress ecosystem.
Understanding the Vulnerability and Its Scope
The wp2shell vulnerability resides within the REST API’s batch endpoint functionality. This endpoint, introduced in WordPress 5.6 in November 2020, allows for multiple API requests to be processed in a single HTTP request. While the batch endpoint itself is not new and its request format has been publicly documented, the specific configuration or a change in WordPress 6.9 inadvertently opened a pathway for exploitation. The exact nature of the change in version 6.9 that led to this vulnerability remains undisclosed by WordPress at this time.
The affected versions are WordPress 6.9.x and 7.0.x. WordPress 7.1 beta2 also carries the same fix. It is important to note that sites running older versions, such as 6.8, may have separate updates pending. For instance, version 6.8.6 addresses a different SQL injection bug that was reported by a separate security research team in the same update cycle.
Estimates suggest that WordPress powers over 500 million websites globally. However, the vulnerable code was introduced in version 6.9, meaning the number of directly affected sites is limited to those running 6.9.x and 7.0.x. While WordPress has not disclosed the exact number of sites running these specific versions, the fact that 6.9 was released relatively recently implies a substantial number of websites were potentially at risk.
WordPress’s Response: Forced Updates and Mitigation Strategies
In response to the critical nature of the vulnerability, WordPress has implemented "forced updates" through its auto-update system. This measure is designed to ensure that even sites that have manually disabled automatic updates receive the security patch. However, WordPress has not explicitly stated whether this forced push extends to sites that have definitively turned off auto-updates. Therefore, website administrators are strongly advised to verify their current WordPress version directly rather than relying solely on the assumption that the update has been applied automatically.
For website owners who are unable to update their WordPress core immediately, Searchlight Cyber has outlined several stopgap measures. These mitigation strategies primarily focus on restricting access to the batch endpoint, thereby preventing anonymous callers from exploiting the vulnerability. The proposed solutions include:
- Web Application Firewall (WAF) Rules: Implementing specific WAF rules to block requests to the
/wp-json/wp/v2/batchendpoint. - Server-Level Access Control: Configuring server access controls (e.g., via
.htaccessor Nginx configuration) to deny access to the batch endpoint for unauthenticated users. - Plugin-Based Blocking: Utilizing security plugins that offer specific features to block access to the REST API batch endpoint.
It is crucial to note that these are temporary solutions. All of them carry the potential to disrupt legitimate integrations or plugins that rely on the REST API batch endpoint for their functionality. Therefore, updating the WordPress core to the patched versions remains the most effective and recommended solution.
Broader Implications and the Cybersecurity Landscape
The discovery and rapid patching of the wp2shell vulnerability highlight several ongoing trends in the cybersecurity landscape, particularly within the WordPress ecosystem. WordPress’s open-source nature means that security patches, while crucial, also make the underlying code publicly accessible. This presents a double-edged sword: while transparency allows for community review and faster bug discovery, it also provides attackers with the "map to the bug." The challenge for open-source projects like WordPress lies in the race between releasing patches and attackers reverse-engineering the fix to develop exploits.
Mass exploitation of WordPress vulnerabilities is a well-documented phenomenon. In the past, even less severe flaws or those requiring specific configurations have been leveraged by sophisticated attack groups to gain access to thousands of websites. The recent mention of the "WP-SHELLSTORM" crew, which reportedly compromised over 17,000 sites through a caching plugin flaw, serves as a stark reminder of the persistent threats faced by WordPress users.
The absence of a CVE (Common Vulnerabilities and Exposures) identifier for this specific flaw, at least by July 18, means that automated scanning tools and vulnerability management systems may not immediately flag it. This further complicates the tracking and remediation efforts for organizations relying on CVE-based security protocols. The Cybersecurity and Infrastructure Security Agency (CISA) also requires a CVE to add vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, a crucial resource for federal agencies and critical infrastructure operators. For now, tracking this vulnerability will rely on monitoring WordPress version numbers.
The decision by Searchlight Cyber to withhold immediate technical details, while providing a public checker, is a strategic move aimed at giving defenders a crucial head start. This contrasts with some past incidents where detailed exploit information became publicly available very rapidly, leading to immediate and widespread attacks. The effectiveness of this approach will be gauged by the speed at which WordPress sites are updated versus the time it takes for attackers to develop and deploy exploits based on the released patch information.
The WordPress development team’s decision to enforce updates demonstrates a recognition of the critical nature of the threat and the need for proactive measures to protect its vast user base. As the internet continues to rely heavily on platforms like WordPress, the ongoing vigilance of security researchers, the swift response of developers, and the diligent updating practices of website administrators will remain paramount in safeguarding the digital landscape. The industry will be closely watching traffic against the /wp-json/wp/v2/batch endpoint for signs of exploitation and monitoring WordPress’s version statistics to ascertain the success of its rapid patching efforts.
