WordPress Core “wp2shell” RCE Flaw: Public Exploits Now Circulating; Patch Immediately

A critical pre-authentication remote code execution vulnerability in WordPress Core, dubbed wp2shell, is now under active exploitation after proof-of-concept code surfaced publicly. The flaw, tracked as CVE-2026-63030, allows an unauthenticated attacker to take complete control of a WordPress site with no login credentials, no special configuration, and no plugins required. WordPress issued emergency security releases on July 17, 2026, and has forced automatic updates for affected installations. If you run WordPress, verify your version now.

How the WP2Shell Attack Chain Works

The vulnerability chains two weaknesses in WordPress’s REST API batch endpoint. An attacker sends a malformed batch request that triggers route confusion — a mismatch between how WordPress maps incoming REST routes and how it validates them. This confusion bypasses normal request handling restrictions and reaches an underlying SQL injection flaw. From there, the attacker can manipulate the database and escalate to full remote code execution on the server.

Security researchers at Searchlight Cyber (Assetnote team), led by Adam Kues, discovered and reported the flaw through WordPress’s HackerOne program. The attack works against a stock WordPress installation with zero plugins enabled. The only requirement is that the site runs an affected version and does not use a persistent object cache, a common default configuration.

The REST API batch endpoint has been part of WordPress Core since version 5.6 and is enabled by default. It is not a niche feature. Any site with pretty permalinks or query-string REST access exposes the vulnerable path.

Affected Versions and Patched Releases

The RCE flaw affects specific version ranges. Sites running anything outside these brackets are not vulnerable to wp2shell itself, though the same security release also fixes a separate SQL injection issue in older branches.

Table

WordPress Branch	Affected Versions	Patched Version
6.9	6.9.0 – 6.9.4	6.9.5
7.0	7.0.0 – 7.0.1	7.0.2
7.1 Beta	Pre-Beta 2	7.1 Beta 2

Versions prior to 6.9.0 are not affected by the RCE chain. WordPress 6.8 is exposed to a separate SQL injection issue, only patched in 6.8.6. The vulnerable code was introduced in WordPress 6.9, which shipped in December 2025.

Public Exploits and In-the-Wild Activity

The risk profile shifted sharply on July 18, 2026, when a public GitHub proof-of-concept repository appeared, demonstrating unauthenticated access to the vulnerable batch endpoint and blind SQL injection techniques against affected versions. While the published PoC did not reproduce the full RCE chain that Searchlight Cyber withheld, it provided enough technical detail for attackers to weaponize the flaw independently.

By the same day, threat intelligence firm WatchTowr reported observing early signs of in-the-wild exploitation targeting the public WP2Shell flaw chain. This marked a rapid escalation from disclosure to real-world attack activity, a timeline measured in hours, not days.

Security vendors responded immediately. Cloudflare deployed blocking WAF rules for both CVE-2026-63030 and the related CVE-2026-60137 on July 17 for all customers. Wordfence added firewall coverage for premium users the same day, with a scheduled rollout for free users on August 16, 2026. Both vendors stressed that WAF filtering is a temporary mitigation only and does not replace patching.

Canadian Impact: Why This Matters North of the Border

WordPress powers an estimated 43 percent of all websites globally, and Canada is no exception. From small business e-commerce stores in Toronto to municipal government sites in rural Alberta, WordPress is the dominant content management platform for Canadian organizations of every size. A pre-authentication RCE in core means that any unpatched Canadian site is a sitting target.

Under Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA), organizations that collect personal information through their websites have a legal obligation to protect that data with appropriate security safeguards. A successful WP2Shell exploitation could lead to unauthorized access to customer databases, payment records, or user credentials, triggering a breach notification requirement to the Office of the Privacy Commissioner of Canada and affected individuals.

The Canadian Centre for Cyber Security (CCCS) has consistently warned that unpatched content management systems remain one of the most common entry points for cyberattacks against Canadian businesses. While the CCCS has not yet issued a specific advisory on wp2shell, the severity of this flaw aligns with the threat profile the center has flagged in past guidance. Canadian IT teams should treat this as a priority one-patching event, regardless of the sector.

What Attackers Can Do With wp2shell

Remote code execution is the most severe class of web vulnerability. A successful WP2Shell exploitation grants the attacker the ability to execute arbitrary server-side code with the permissions of the web server process. Practical consequences include the following:

• Defacing the site or injecting malicious redirects
• Stealing database contents, including user credentials and payment data
• Creating hidden administrator accounts for persistent access
• Installing backdoors, web shells, or cryptocurrency miners
• Pivoting from the web server to internal network resources
• Using the compromised site as a staging ground for phishing or malware distribution

Because the attack requires no authentication, an attacker can scan the internet for vulnerable sites and exploit them at scale. The public availability of exploit code makes mass exploitation a near-certainty.

Temporary Mitigations If Patching Is Delayed

If an immediate update is genuinely impossible, the following emergency measures can reduce exposure. Treat each as a temporary bridge, not a substitute for patching.

Block the Batch Endpoint at the Firewall

Configure WAF rules to block anonymous requests to both paths:

• /wp-json/batch/v1
• ?rest_route=/batch/v1

Blocking only the pretty-permalink path leaves the query-string alternative wide open. Cloudflare has already deployed these rules for its customers.

Disable REST API Access for Anonymous Users

Plugins that disable the REST API for unauthenticated visitors can block the attack vector. Be aware that this may break legitimate integrations, contact forms, or headless CMS functionality.

Use the researcher’s drop-in mitigation.

Searchlight Cyber published a small must-use plugin available from wp2shell.com that rejects anonymous batch requests. The site has experienced intermittent outages due to high traffic, so do not rely on it as a permanent solution.

Key Takeaways

• CVE-2026-63030 (wp2shell) is a critical unauthenticated remote code execution flaw in WordPress Core that requires no plugins or login credentials to exploit.
• Affected versions are WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1, with fixes available in 6.9.5 and 7.0. 2.
• Public proof-of-concept code is now available on GitHub, and threat intelligence firms have reported early signs of in-the-wild exploitation.
• WordPress has enabled automatic updates for affected sites, but administrators must verify that the update has actually completed.
• Canadian organizations face PIPEDA breach notification obligations if customer data is compromised through this flaw.
• WAF rules from Cloudflare and Wordfence provide temporary filtering but do not replace the core patch.
• The attack chains the REST API route confusion with SQL injection to achieve full server compromise.

What You Should Do Now

1. Verify your WordPress version immediately. Open Dashboard → Updates and confirm you are running 7.0.2, 6.9.5, 6.8.6, or 7.1 Beta 2. Do not assume a background update succeeded; check manually.
2. Check every instance. Production sites, staging environments, client subdomains, and forgotten test installations all need verification. One missed site is one compromised site.
3. Test functionality after patching. Load the public site and test critical forms, checkout flows, and the admin dashboard. Confirm no maintenance-mode files or PHP errors remain.
4. Preserve logs before cleanup. If you suspect a site was compromised before patching, archive web server logs, WAF logs, and authentication records before removing any backdoors.
5. Inspect for compromise indicators. Review administrator accounts, application passwords, recently modified core files, active themes, plugins, mu-plugins scheduled tasks, and unexpected PHP files in writable directories. Look for unexplained redirects or changes.
6. Rotate credentials if compromise is plausible. Change database passwords, hosting credentials, WordPress salts, and admin passwords. Revoke active sessions and review API keys.
7. Remove temporary WAF blocks only after confirming the patch. Once the update is verified and required integrations tested, lift any emergency firewall rules that may be blocking legitimate REST API traffic.