--- title: "WordPress WP2Shell Flaws Now Under Active Exploitation" date: 2026-07-20 author: "Sofia Ramirez" featured_image: "https://sqmagazine.co.uk/wp-content/uploads/2026/07/wordpress-wp2shell-flaws-now-under-active-exploitation.jpg" categories: - name: "Cybersecurity" url: "/cybersecurity.md" tags: - name: "News" url: "/tag/news.md" --- # WordPress WP2Shell Flaws Now Under Active Exploitation 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](https://nvd.nist.gov/vuln/detail/CVE-2026-63030) 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. 🤦‍♂️ > > 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](https://t.co/1S1cw0z1ss) > > — SOCRadar® (@socradar) [July 20, 2026](https://x.com/socradar/status/2079251240446464268?ref_src=twsrc%5Etfw) ## 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](https://sqmagazine.co.uk/cloudflare-statistics/) has separately rolled out rules to detect exploitation and protect customers whose installations were not immediately patched. [WordPress](https://sqmagazine.co.uk/wordpress-statistics/) 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](https://sqmagazine.co.uk/ai-tools-usage-statistics/). 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](https://sqmagazine.co.uk/cve-statistics/). 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](https://sqmagazine.co.uk/web-hosting-statistics/) 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.