A Hacker Left His Server Open for 22 Days. Inside: 1.4 Million WordPress Targets, 27 Weaponized CVEs, and a Webshell Kit Called WP-SHELLSTORM.
- Patrick Duggan
- 2 days ago
- 4 min read
The best threat intelligence of the weekend did not come from a vendor's telemetry or a honeypot. It came from an attacker who forgot to close a door. Someone running a professional WordPress mass-compromise operation stood up a plain Python SimpleHTTPServer to move files around, and left it facing the internet for twenty-two days. Researchers found it, and inside was the entire business: the toolkit, the logs, the target lists, and the receipts. The operation has a name now — WP-SHELLSTORM — because its own operator's operational security handed us one.
The numbers in that open directory are the kind you have to read twice. More than 1.4 million WordPress domains on the target lists. Twenty-seven separate CVEs weaponized into the toolkit. More than 5,700 webshells confirmed still live on compromised sites, with public reporting putting the count of backdoored victims around 25,000. This is not a smash-and-grab. It is an access-brokerage operation — compromise at industrial scale, then sell or rent the foothold — and for twenty-two days its filing cabinet was unlocked on the sidewalk.
First, do not confuse it with the other WordPress story this weekend
There are two WordPress emergencies in the news right now with names close enough to swap by accident, and telling them apart matters because the fix for one does nothing for the other.
wp2shell is CVE-2026-63030, a pre-authentication remote code execution flaw in WordPress core, patched in the emergency 7.0.2 and 6.9.5 releases. We wrote about that one yesterday. You fix it by updating WordPress itself.
WP-SHELLSTORM — this story — is not a core flaw and not a single CVE. It is a campaign: a crew that mass-exploits sites running out-of-date plugins, drops a webshell, and keeps the access. Updating core does not save you here. Auditing your plugins and hunting for the webshell does. Same platform, same weekend, nearly the same name, completely different homework.
The weapon of choice is one we already flagged in May
The single biggest producer of victims in the WP-SHELLSTORM haul was not some exotic zero-day. It was CVE-2026-3844, the unauthenticated RCE in the Breeze caching plugin — the one on more than four hundred thousand WordPress sites. The toolkit fired it at more than 45,000 targets and backdoored over 17,000 of them. It was the crew's workhorse.
We published the hunt for that exact flaw on May 8, when Wordfence was logging active exploitation before the patch had even fully propagated. So the through-line is not that we predicted a campaign nobody could name yet. It is narrower and more honest than that: the vulnerability that did the most damage in this operation is one a defender following our feed had detection guidance for two months before the operator's open directory made the campaign a headline. The patch was available. The plugin update was available. Seventeen thousand sites ran it vulnerable anyway, which is the real lesson and the depressing one — the gap is never the disclosure, it is the box that never got patched.
What to hunt for tonight
Because the toolkit leaked, the indicators are unusually concrete, and they split into two kinds. Block the network ones; grep for the host ones.
On the network side, three indicators are worth putting in your blocklist immediately: the IP addresses 137.175.93.126 and 43.108.17.80, and the callback domain xs.xxooonline.eu.cc. We have already ingested these into our feed under the WP-SHELLSTORM label, so anyone pulling our IP and domain blocklists inherits them without lifting a finger — that is what the free feed is for.
On the host side, the webshell files hide behind deliberately boring, dot-prefixed names that blend into a WordPress directory listing. Search your webroot for files named like .bd.php, .wp-log.php, .brq-.php, .sd.php, .leo_.php, .wvp-.php, .cc-.php, .nf-log.php, and anything matching BZ_ followed by .phtml. The primary webshell, dropped as down.php, has the SHA256 hash 84f7e396a48913851a10cc78c5cc22a25634564abd0694465236d2f365e2bdee.
There is one more indicator worth knowing because it is elegant and easy to check. The crew disguises a malicious process by naming it to look like a Linux kernel worker thread — something in the form of a bracketed kworker with numbers. Here is the tell: a real kernel thread is not a program. It has no executable on disk, no command line, and opens no network sockets. So if you find a process presenting itself as a bracketed kworker and it has an executable path, a command line, or an open socket, it is an impostor wearing the kernel's uniform. That single check separates the real thing from the disguise every time.
The honest edges
Two things worth stating plainly, because the point of this shop is to say them.
First, our contribution to the feed here is attribution and distribution, not discovery. Researchers found the open server; we are not claiming we did. What we did is what a defender actually needs next — validate the indicators, tag them to the campaign, and push the blockable ones into a free feed with the provenance cited, so a cash-poor site owner who will never read the original research still gets the protection. The receipt we own outright is the May 8 Breeze hunt, and we are putting the comparator timestamp right next to it rather than dressing this up as a prediction it was not.
Second, we put confidence at about 95 percent that the network indicators above are worth blocking today, and we will tell you where the 5 percent lives: an access-brokerage crew rotates infrastructure, and an IP that was central when the server was exposed can be cold by the time you read this. Block it anyway — a stale malicious IP costs you nothing — but do the host-side hunt regardless, because the webshell on your own box does not rotate. It just sits there with the door open, exactly the way its operator's server did for twenty-two days.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments