wp2shell WordPress Vulnerabilities (CVE-2026-60137 and CVE-2026-63030) Confirmed Exploited in the Wild
wp2shell moves from disclosure to active exploitation — defender teams and hosting providers accelerate verification this week.
The wp2shell flaws have crossed from disclosure to confirmed exploitation in days — turning patch verification across every hosted WordPress property into this week's highest-value defender task.
SAN FRANCISCO, CALIF. — The pair of WordPress vulnerabilities disclosed last week as wp2shell is now being exploited in the wild, SecurityWeek reported on July 20, 2026, with attacks beginning shortly after the flaws came to light. The two issues are officially tracked as CVE-2026-60137, a high-severity SQL injection bug, and CVE-2026-63030, a critical arbitrary code execution vulnerability; chained together, SecurityWeek reported, they allow an attacker to achieve unauthenticated remote code execution on affected WordPress websites, giving threat actors control of targeted sites.
The exploitation confirmation converts a patch-verification exercise into an active-response one. WordPress shipped fixes in versions 6.9.5 and 7.0.2 on Friday and enabled forced updates through its auto-update system for sites running affected versions. But the operative fact for defenders is that the window between disclosure and exploitation has already closed — any WordPress deployment still on the 6.9 legacy branch or an unpatched 7.0.x release should be treated as exposed until a fixed version is confirmed running.
What SecurityWeek Reported
SecurityWeek reported on July 20 that the two newly patched WordPress vulnerabilities are being exploited in the wild, with attacks beginning shortly after the flaws came to light. The vulnerabilities were dubbed WP2Shell — this article uses wp2shell after first reference — and are officially tracked as CVE-2026-60137 and CVE-2026-63030. Per Searchlight Cyber, whose researchers discovered the flaws, WordPress versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 are affected; the firm warned that "the attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins."
On the vulnerability classes, SecurityWeek reported that CVE-2026-60137 is a high-severity SQL injection bug and CVE-2026-63030 is a critical arbitrary code execution vulnerability. Chaining the two enables an attacker to achieve unauthenticated remote code execution on affected websites, allowing threat actors to take control of targeted sites. The CyberSignal is not reconstructing the exploitation path; the operative facts are the affected and fixed versions and the confirmation that attacks are underway.
The in-the-wild exploitation was confirmed by several cybersecurity firms, according to SecurityWeek, including the WordPress security company Patchstack. Hexastrike began seeing exploitation attempts in its honeypots over the weekend and said it had assisted with incident response in several attacks; WatchTowr also reported in-the-wild exploitation attempts. "This is going to hurt," WatchTowr CEO and founder Benjamin Harris told SecurityWeek, noting that while some of the hundreds of millions of WordPress sites will be auto-patched by their hosting providers, "plenty will not, and that is where the damage will be done." WordPress enabled forced updates via the auto-update system for affected sites, and Cloudflare rolled out rules to detect exploitation for customers whose installations were not immediately patched.
Continuation Context: Brief #244 (wp2shell Disclosure) and Brief #252 (WordPress 7.0.2 Patch)
This is the third entry in The CyberSignal's wp2shell thread. The flaw was first covered when CVE-2026-63030 was disclosed as a critical unauthenticated remote code execution issue in WordPress Core, reachable via the REST API batch route and requiring no valid account, and again when WordPress shipped the 7.0.2 security release pairing it with the CVE-2026-60137 SQL-injection flaw. What today's reporting adds is the one variable those pieces left open: exploitation status has moved from unconfirmed to confirmed.
One point from the earlier coverage bears a careful restatement, because it is easy to get wrong. At disclosure there was no public proof-of-concept: Searchlight Cyber withheld the technical exploit details, and the sibling briefs correctly recorded that none had been published. That has since changed. SecurityWeek reports that while Searchlight has not released details to prevent abuse, proof-of-concept exploits have been made public by others, and Harris said his firm saw PoCs appear within hours of disclosure — faster than the day-or-more such code historically took. Nothing about the earlier record was wrong; the point is that the quiet window the disclosure briefs described has now closed, exactly as they cautioned it would.
Accelerated Defender Action for WordPress Deployments
The remediation instruction has not changed since the patch shipped: update to WordPress 6.9.5 or 7.0.2. What has changed is the clock behind it. With exploitation confirmed, the difference between patch availability and patch verification that recurs in nearly every content-management-system incident is no longer theoretical — it is the gap attackers are working through this week. Forced auto-updates carry a load-bearing condition: they reach installations with automatic updates enabled, and the sites most likely to have that switched off are the bespoke, heavily customised, or deliberately pinned ones that rarely sit in a central inventory.
The population that has to do this work is broad. Digital agencies with hundreds of client sites, hosting providers with fleets in the thousands, and marketing teams running campaign microsites all hold assets on the affected 6.9 branch or an unpatched 7.0.x release. The task is a version query executed as an emergency rather than a maintenance item: enumerate every WordPress instance under management, find anything on 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1, and confirm a fixed version is actually running rather than queued. Because exploitation is active, verification should now be paired with a look for signs of intrusion; Hexastrike has published recommendations for detecting and investigating attacks on affected sites.
The pattern echoes prior WordPress-side incidents The CyberSignal has tracked, from the Gravity SMTP plugin API-key exposure to the SocGholish botnet takedown that cleaned up thousands of compromised WordPress sites. What sets wp2shell apart is that CVE-2026-63030 sits in WordPress Core: the exposure question is not what was installed, but what version is running.
What a CISA KEV Addition Should Be Watched For
As of publication, neither CVE-2026-60137 nor CVE-2026-63030 is confirmed as added to CISA's Known Exploited Vulnerabilities catalog. With exploitation now publicly confirmed by multiple firms, a KEV listing is the specific event defenders should watch for next: it would formalise the exploitation finding into a federal catalog entry and attach remediation deadlines for US civilian agencies under Binding Operational Directive 22-01, converting a recommendation into a compliance clock. A core-level unauthenticated RCE in the web's most-deployed CMS, now with attacks in the wild, is precisely the profile that draws a KEV entry — so the absence of one today should read as "not yet listed," not "not urgent."
The broader arc is the one the 2026 Verizon DBIR flagged when it found vulnerability exploitation had overtaken credential theft as the leading initial-access method. wp2shell is a textbook instance: a core-level flaw, weaponised within hours by AI-assisted tooling, against a platform running on hundreds of millions of sites.
Open Questions
Several material points remain unestablished. No named threat actors have been attributed to the exploitation, and the total number of confirmed victim sites is not established — the reporting confirms that attacks are underway across multiple firms' telemetry without quantifying compromise. Whether either CVE will be added to CISA's KEV catalog is unconfirmed at the time of writing.
It is also not established whether hosting providers have deployed platform-wide mitigations beyond the WordPress forced-update mechanism and Cloudflare's detection rules. This uncertainty is itself the argument for per-site verification: a defender cannot assume a provider-level control caught a given property, and the recurrence of SQL-injection and CMS-core flaws — from Drupal core to the Ghost CMS issue abused in a ClickFix campaign across roughly 700 sites — is a reminder that the responsibility lands on whoever operates the site.
The CyberSignal Analysis
The facts above come from SecurityWeek's reporting and the prior advisories. What follows is The CyberSignal's editorial reading of what operators should take from the exploitation confirmation; none of it introduces new reported facts.
Signal 01 — Exploitation Confirmed Changes the Deadline, Not the Fix
The remediation was always "update to 6.9.5 or 7.0.2." What the in-the-wild confirmation changes is the tolerance for delay. A team that had this queued for the next maintenance window should now treat it as an active-response item: the same patch, executed against a compressed clock, plus a scan for signs that an unpatched site was already reached. The update that closes both CVEs is one action; the new element is urgency, not scope.
Signal 02 — "The Window Has Collapsed" Is the Planning Assumption Now
WatchTowr's Harris framed wp2shell as the latest case of AI-assisted tooling weaponising a disclosure within hours rather than a day or more. For defenders, the operational takeaway is that "no public exploit yet" is no longer a meaningful buffer to plan around — as the sibling disclosure briefs cautioned, the quiet period is a countdown of unknown but short duration. Programmes that key their SLA to the appearance of exploit code will keep losing this race; the trigger to act is disclosure of an unauthenticated RCE, not the later confirmation that it is being used.
Signal 03 — Forced Updates and Provider Rules Reduce the Problem, They Do Not Close It
WordPress forcing auto-updates and Cloudflare shipping detection rules will resolve much of the install base quietly, and that is genuinely useful. But both are conditional: forced updates reach only sites with auto-update enabled, and provider-level rules protect only customers behind them. The responsible posture is to treat these mechanisms as shrinking the exposed population rather than eliminating it, and to verify per site — because the properties that fall through both gaps are exactly the forgotten, pinned, or self-hosted ones least likely to appear on anyone's list.
