Public exploit code targeting two critical WordPress core vulnerabilities became available on GitHub by July 19, 2026, according to Searchlight Cyber. The attack chain, called "wp2shell," combines CVE-2026-63030 and CVE-2026-60137 to enable unauthenticated remote code execution on WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1. Patches are available in versions 6.9.5 and 7.0.2.
TL;DR: Two WordPress core vulnerabilities now have public GitHub exploits that allow attackers to execute code without logging in; immediate updates to 6.9.5 or 7.0.2 required.
The vulnerabilities work on default WordPress installations without requiring any plugins, meaning hundreds of millions of sites worldwide are potentially exposed if administrators delay patching. WordPress has enabled forced automatic security updates for supported sites running affected versions, but manual verification remains necessary for sites where auto-updates are disabled or custom configurations block them.
The Attack Chain
CVE-2026-63030 is a REST API batch-route confusion bug introduced in WordPress 6.9, while CVE-2026-60137 is an SQL injection vulnerability in the author__not_in parameter of WP_Query. Individually, both flaws pose security risks, but chaining them together creates a complete remote code execution pathway that bypasses authentication.
The SQL injection flaw also exists in WordPress 6.8.x, according to the Searchlight Cyber analysis, but cannot be weaponized into remote code execution in that version because the REST API vulnerability was not present until 6.9. The attack requires no administrator credentials and works against a fresh WordPress installation with no third-party plugins installed.
Searchlight Cyber delayed publishing full technical details to give site owners patching time, but multiple proof-of-concept exploits appeared on GitHub shortly after the disclosure. Some of these exploit scripts extract password hashes before attempting to crack administrator credentials, while others claim to achieve direct code execution without requiring any existing access.
Active Exploitation and Timeline
Security researchers reported the first signs of real-world exploitation attempts beginning July 19, 2026. This pattern typically accelerates once public exploit code becomes available, as automated scanning tools quickly incorporate new attack signatures. Agencies managing client sites at scale should treat this as an immediate WordPress development services priority.
Cloudflare deployed Web Application Firewall protections for both vulnerabilities across all service tiers, including free accounts, on July 19, 2026. The company emphasized that WAF rules block known exploit patterns but do not replace installing the official security patches released by WordPress.
The timing compounds risk for agencies operating white-label WordPress development at scale. Client sites that disable auto-updates or run custom configurations require manual patch deployment, creating a window where attackers with public exploit code can compromise unpatched installations. This vulnerability follows a pattern of escalating WordPress plugin vulnerabilities throughout 2026, with the WordPress ecosystem reporting 250-plus weekly plugin vulnerabilities, 43 percent exploitable without authentication.
Immediate Mitigation Steps
For sites running WordPress 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1, updating to version 6.9.5 or 7.0.2 should be the highest operational priority. Agencies should audit every client site under management, particularly those with auto-updates disabled or running custom hosting configurations that may block WordPress's forced update mechanism.
Temporary workarounds include blocking anonymous access to the WordPress REST API or blocking the affected batch API endpoints using a Web Application Firewall. Searchlight Cyber launched a vulnerability checker website that allows administrators to verify whether their installations are exposed, but emphasized that these are stopgap measures only. Installing the official security update is the only reliable way to eliminate the risk.
For agencies managing 50-plus client sites, this incident highlights the operational value of centralized patch management and monitoring systems. Sites without active maintenance contracts or regular WordPress performance optimization workflows are statistically more likely to remain unpatched beyond the critical 48-hour window when exploit activity peaks.
The Australian Cyber Security Centre issued a similar warning earlier in 2026 when attackers deployed web shells through known WordPress and Joomla vulnerabilities, underscoring the pattern of core CMS vulnerabilities becoming high-value targets once public exploits emerge.
Why This Matters Now
The wp2shell vulnerability chain represents a shift in WordPress core security risk. Unlike plugin-specific flaws that affect limited subsets of installations, these vulnerabilities target default WordPress core functionality and require no third-party code to exploit. For agencies selling white-label WordPress development, this creates liability exposure across every client site running affected versions.
Agencies should implement three immediate operational changes. First, audit every client site for version numbers and patch status within the next 24 hours, prioritizing sites with public-facing forms, user authentication, or e-commerce functionality. Second, establish a documented incident response protocol for zero-day WordPress core vulnerabilities that includes client notification requirements and emergency patching workflows. Third, review maintenance contracts to ensure patch deployment timelines are explicitly defined and clients understand the risk window between disclosure and remediation.
The availability of public GitHub exploits compresses the decision window. Attackers using automated scanning tools can identify and compromise vulnerable sites faster than manual agency patch cycles can respond, particularly for agencies managing distributed client portfolios without centralized update management. This incident validates the operational case for maintenance retainers that include proactive security monitoring and emergency patch deployment as standard deliverables rather than reactive add-ons.