wp2shell WordPress Mass Exploitation Expands; Millions of Sites at Risk

wp2shell has crossed from confirmed exploitation into indiscriminate mass scanning in days — turning per-site patch verification across every hosted WordPress property into this week's highest-value defender task.

SAN FRANCISCO, CALIF. — Exploitation of the pair of WordPress Core vulnerabilities dubbed wp2shell has expanded from confirmed in-the-wild attacks into indiscriminate mass scanning, according to multi-source reporting published July 20 and 21, 2026. The two issues are tracked as CVE-2026-63030, a critical REST API batch-route confusion flaw, and CVE-2026-60137, a SQL injection bug; chained together they allow an unauthenticated attacker to achieve remote code execution against affected WordPress websites. Dark Reading, which refers to the pair as "WP2Shell," estimates that millions of sites are at risk of remote takeover as public exploit code circulates.

The scale is the story. The Hacker News reported that watchTowr's honeypots have registered tens of thousands of exploitation attempts, and that public exploit code is now fueling widespread scanning across organizations of every size and vertical. For hosting providers and defender teams, the reporting converts an active-response exercise into a fleet-wide one: the population of exposed properties is no longer measured in named victims but in the share of the install base still running an unpatched version.

What Multi-Source Reporting Documented

Coverage across several outlets on July 20 and 21 converged on the same picture: attacks that began shortly after disclosure have broadened into large-scale, opportunistic scanning. The Hacker News reported that public exploit code is fueling mass scanning, with watchTowr's Jake Knott describing "widespread impact of this vulnerability across organizations of every size and every vertical." Dark Reading, under the headline "'WP2Shell' Opens Millions of WordPress Sites to Remote Takeover," framed the exposure at the scale of the install base rather than a discrete victim count. The Register, TechCrunch, and the SANS Internet Storm Center added further confirmation that exploitation is underway and expanding.

On the mechanics, the reporting is consistent with the prior advisories and does not require reconstruction here: CVE-2026-63030 is the REST API batch-route confusion flaw that yields remote code execution, and CVE-2026-60137 is the SQL injection issue, with the two chained for unauthenticated compromise. The Register reported that multiple proof-of-concept exploits are now in the public domain, which is the variable that turns a confirmed-exploitation story into a mass-scanning one. TechCrunch, like Dark Reading, put the population reportedly at risk in the millions. The CyberSignal is not reproducing exploit detail; the operative facts are the affected-and-fixed versions and the shift to indiscriminate scanning.

Continuation Context: Brief #244 (Disclosure), Brief #252 (7.0.2 Patch), Brief #258 (Initial Exploitation)

This is the fourth entry in The CyberSignal's wp2shell thread, and the sequence matters for calibrating urgency. The flaw was first covered when CVE-2026-63030 was disclosed as a critical unauthenticated remote code execution issue in WordPress Core, reachable through the REST API batch route and requiring no valid account. Coverage continued when WordPress shipped the 7.0.2 security release pairing it with the CVE-2026-60137 SQL-injection flaw, and again when reporting confirmed the wp2shell flaws had moved from disclosure to active exploitation in the wild.

What today's reporting adds is a change in degree that becomes a change in kind. The earlier entries described exploitation confirmed by a handful of firms' telemetry; the current coverage describes indiscriminate scanning at internet scale, driven by public exploit code. The disclosure briefs cautioned that the quiet window before public exploits appeared was a countdown of unknown but short duration. That window has not only closed — the mass-scanning phase the sequence anticipated has now arrived.

Accelerated Defender Action for WordPress Deployments

The remediation instruction is unchanged: get affected installations onto WordPress 6.9.5 or 7.0.2. What the mass-scanning phase changes is the tolerance for delay and the breadth of the audience that has to act. WordPress took the rare step of forcing automatic updates for affected installs, which will resolve much of the population quietly — but the gap between patch availability and verified patch application is exactly the space that opportunistic scanning is built to find. Forced updates reach only installations with automatic updates enabled, and the sites most likely to have that switched off are the bespoke, heavily customized, or deliberately pinned ones that rarely appear in a central inventory.

The population that has to do this work is broad and largely institutional. Hosting providers with fleets in the thousands, digital agencies managing hundreds of client sites, and marketing teams running campaign microsites all hold assets that may still be on an unpatched branch. The task is a version query executed as an emergency: enumerate every WordPress instance under management, find anything still exposed, and confirm a fixed version is actually running rather than merely queued. Because scanning is indiscriminate and public exploits are circulating, verification should be paired with a hunt for signs of intrusion — new administrator accounts, unexpected plugins, or unfamiliar files — regardless of whether a site is now believed patched, since a fast-moving scan may have reached it before the fix landed.

The pattern echoes prior WordPress-side incidents The CyberSignal has tracked, including the SocGholish botnet takedown that cleaned up thousands of compromised WordPress sites. What sets wp2shell apart is that the flaws sit in WordPress Core: the exposure question is not what plugin was installed, but what version is running — which is precisely why a fleet-wide version audit, not a plugin review, is the correct instrument this week.

The AI-Assisted-Exploit-Development Angle

One thread running through this cycle deserves careful, attributed handling. Infosecurity Magazine reported that a researcher used OpenAI's latest model to develop the exploit chain for the two WordPress Core vulnerabilities. The account is a researcher's own demonstration of AI-assisted vulnerability work rather than a claim about how the in-the-wild attacks were built, and The CyberSignal reproduces it only at the level Infosecurity Magazine reported it — no version-specific model claim and no methodology.

The relevance for defenders is directional, not tactical. It fits a pattern The CyberSignal has tracked in cases such as the first AI-developed zero-day tied to mass exploitation, and it reinforces the broader shift documented in coverage of how AI is being used across the attack lifecycle. The planning takeaway is that the interval between disclosure and a working, public exploit is compressing, so "no public exploit yet" is no longer a buffer defenders can build a remediation SLA around.

Open Questions

Several material points remain unestablished. The total number of confirmed compromised sites is not established — the reporting documents mass scanning and exploitation attempts at scale without quantifying successful takeovers, and the "millions at risk" figure describes exposure, not confirmed compromise. No named threat operators have been attributed to the campaign.

It is also not confirmed whether either CVE has been added to CISA's Known Exploited Vulnerabilities catalog, nor whether hosting providers have deployed platform-wide mitigations beyond the WordPress forced-update mechanism. That uncertainty is itself the argument for per-site verification: a defender cannot assume a provider-level control caught a given property. 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 — a core-level flaw in the web's most-deployed CMS, now scanned indiscriminately, is a textbook instance of it.

The CyberSignal Analysis

The facts above come from the multi-source reporting cited and the prior advisories. What follows is The CyberSignal's editorial reading of what operators should take from the mass-scanning phase; none of it introduces new reported facts.

Signal 01 — Scale Changes the Instrument, Not the Fix

The remediation was always "update to 6.9.5 or 7.0.2." What the mass-scanning phase changes is how you find the work: not by triaging named victims but by auditing the whole fleet, because indiscriminate scanning does not select targets — it enumerates them. For a hosting provider or agency, the correct move is an inventory-wide version query executed as an incident, paired with an intrusion check on anything that was exposed while public exploits were live.

Signal 02 — "No Public Exploit Yet" Is No Longer a Buffer

This cycle is a clean illustration of a collapsing timeline: disclosure, then confirmed exploitation, then indiscriminate scanning fueled by public exploit code, in a matter of days — with a researcher separately demonstrating AI-assisted development of the chain. Programs that key their patch SLA to the appearance of exploit code will keep losing this race. The trigger to act is disclosure of an unauthenticated core-level RCE, not the later confirmation that it is being scanned for at scale.

Signal 03 — Forced Updates Shrink the Problem; They Do Not Close It

WordPress forcing automatic updates will quietly resolve much of the install base, and that is genuinely useful. But it is conditional: forced updates reach only sites with auto-update enabled, and the properties that fall through that gate are exactly the forgotten, pinned, or self-hosted ones least likely to sit on anyone's list. Treat platform-level mechanisms as shrinking the exposed population, not eliminating it, and verify per site — because at internet-scale scanning, the long tail is where the compromises land.

Sources