WordPress released emergency patches for two chained vulnerabilities dubbed WP2Shell on July 17, 2026, after researchers found the flaws let an anonymous attacker exploit a stock install of WordPress with no plugins. Multiple security firms now confirm active exploitation of unpatched sites.
Quick Summary – TLDR:
- The WP2Shell bugs were fixed, according to WordPress, on July 17, 2026, shipping versions 6.9.5 and 7.0.2 to close both holes.
- Chaining the two bugs lets an attacker achieve unauthenticated remote code execution on affected WordPress websites, per NVD’s vulnerability record.
- WordPress turned on forced automatic updates for affected sites, according to WordPress developers, because of how severe the bugs are.
- Hackers have confirmed in-the-wild exploitation, according to Patchstack, Hexastrike and WatchTowr, and public proof-of-concept exploit code is already circulating.
- Over 500 million websites run WordPress, according to Searchlight Cyber, which discovered the bugs.
What Happened?
The two flaws, tracked as CVE-2026-60137 and CVE-2026-63030, were credited to two separate sets of researchers. One team reported the underlying SQL injection issue, while a REST API batch-route confusion and SQL injection issue leading to remote code execution was reported by Adam Kues at Assetnote / Searchlight Cyber.
CVE-2026-60137 is a high-severity SQL injection bug and CVE-2026-63030 is a critical arbitrary code execution vulnerability. The NVD record splits the severity call: WPScan’s CNA scoring rates CVE-2026-63030 at 9.8 CRITICAL, while CISA-ADP rates it 7.5 HIGH.
WordPress versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 are affected by the full exploit chain. The attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins.
WordPress also backported a fix for the SQL injection alone to version 6.8.6, since that flaw reaches back further than the batch-route bug that turns it into full code execution.
A WordPress RCE that doesn’t even need a plugin to ruin your day. 🤦♂️
— SOCRadar® (@socradar) July 20, 2026
wp2shell (CVE-2026-63030 + CVE-2026-60137) is a pre-auth RCE chain in WP core. No login needed. Exploit code is already in the wild.
Use our free checker (no signup) to verify your exposure, mitigate the risk,… pic.twitter.com/1S1cw0z1ss
Inside the WP2Shell Attack Chain
The exploit combines two separate design flaws, according to a technical breakdown Patchstack published on its own site. The critical issue is an unauthenticated SQL injection reachable through the REST API’s batch endpoint, via a route/handler confusion that defeats input validation. NVD describes the same chain as a REST API batch endpoint route confusion issue that, combined with the author__not_in WP_Query SQL injection tracked as CVE-2026-60137, could let an attacker perform SQL injection and achieve remote code execution.
Patchstack said it independently verified the combined bugs can lead to full site takeovers, including remote code execution, and that it has already seen exploitation attempts in its own logs after deploying detection rules. Cloudflare has separately rolled out rules to detect exploitation and protect customers whose installations were not immediately patched.
WordPress runs on hundreds of millions of websites globally. Some of those will be auto-patched by their hosting providers, but plenty will not, and that is where the damage will be done.
Harris also pointed to a broader pattern behind how fast this one moved from disclosure to attack. This is also the latest example in a clear trend of vulnerabilities being surfaced by AI-assisted tooling. We saw PoCs appear within hours of disclosure, where historically that would have taken 24 hours or more.
That collapsing window matters more than the CVE count. A defender who used to have a day between a public disclosure and a working exploit now has hours, which turns a leisurely patch cycle into an immediate one for anyone running exposed WordPress core.
What This Means for Site Owners?
Forced auto-updates cover a lot of ground, but not automatically every site. A forced update still runs through each site’s own auto-update system, so a site where an owner or host has switched automatic updates off, or where WordPress core is deployed through a custom pipeline outside that system, will not receive the fix on its own. Those are exactly the installs still exposed to an unauthenticated, no-plugin exploit chain a week after the patch shipped.
Site owners who manage updates manually should confirm they are running WordPress 7.0.2, or 6.9.5 on the 6.9 branch, or 6.8.6 on the 6.8 branch rather than assuming a host applied the patch. Reviewing recent site administrator accounts for anything unrecognized is a reasonable next step given confirmed in-the-wild activity, though no update or firewall rule guarantees a compromised site was caught before the patch landed. It only helps reduce the exposure window.
SQ Magazine’s Takeaway
WP2Shell is not really a story about one weak parameter. It is a story about how little distance now separates a public disclosure from a working, unauthenticated exploit against one of the most widely deployed pieces of software on the internet. WordPress’s decision to force the update, rather than merely publish it, reflects that reality: a normal disclosure then wait cycle was not going to outrun the attackers this time.
What’s Next: expect hosting providers to publish their own patch-compliance numbers over the coming days, and expect Patchstack, Hexastrike and WatchTowr to keep updating exploitation counts as more honeypot data comes in. Site owners on managed hosting should verify the forced update actually applied rather than assume it did, and anyone running WordPress through a custom deployment pipeline that blocks auto-updates should treat this as an immediate, not a next-sprint, patch.
