WP-SHELLSTORM: What an Exposed Hacker Server Teaches Us About Credential Theft at Scale

A Careless Operator, A Very Revealing Server

Sometimes the most instructive security incidents are the ones where attackers expose themselves. According to reporting by The Hacker News, a cybercrime crew left one of its own servers publicly accessible — no password, no access controls — for approximately three weeks. Two independent research teams, SOCRadar and Ctrl-Alt-Intel, discovered the open directory and found roughly 800MB of operational material inside: exploit scripts, webshells, scan logs, and a detailed command history.

The operation, tracked as WP-SHELLSTORM, reportedly functioned as a webshell access brokerage — breaking into websites at scale, planting hidden backdoors, and packaging that access for resale. The primary targets were WordPress sites running outdated plugins, though Joomla installations also appeared prominently in the crew’s target lists.

The scale sounds alarming at first: more than 1.4 million domains reportedly appeared across the crew’s target files. But researchers were careful to distinguish between sites that were scanned and sites that were actually compromised. Ctrl-Alt-Intel’s deduplicated count found roughly 25,000 sites with confirmed compromise evidence; SOCRadar put active webshells at just over 5,700. Being on an attacker’s scan list is meaningfully different from being breached.

The Credential Harvest Nobody Led With

The WordPress backdooring drew the headlines, but the earlier phase of this operation is arguably more relevant to enterprise security teams.

According to SOCRadar’s findings, before the noisy, high-volume WordPress campaign, the same crew conducted a quieter operation in early May 2026 against corporate Java systems. Reportedly, they pulled configuration files from systems across companies in fintech, e-commerce, logistics, gaming, and electronics. What came out of those systems is the part worth dwelling on:

• Cloud access keys for AWS, Alibaba Cloud, Oracle, Tencent, and DigitalOcean
• Database passwords stored in configuration files
• RSA private keys for payment services

The entry point, reportedly, was CVE-2021-29441, an old and well-documented flaw in Nacos, a configuration management server. The vulnerability allows an attacker to bypass authentication entirely by manipulating a single web request header. It was patched years ago, and yet it reportedly delivered 613 configuration files from 11 systems.

SOCRadar’s analysis described the sequencing as deliberate: harvest high-value corporate credentials first, then scale into the higher-volume backdoor work. Whether or not that interpretation is correct, the pattern is a familiar one in incident response — configuration files and secrets stores are frequently underestimated as targets, and their exposure often goes undetected far longer than endpoint or identity provider compromises.

What Identity and Access Teams Should Take Away

Several practical lessons emerge from the WP-SHELLSTORM operation that apply well beyond WordPress administrators.

Exposed secrets in configuration files are a critical risk surface. Cloud keys, database credentials, and private keys stored in application configuration files represent a class of secret that many organizations do not rotate on any regular cycle, and often do not monitor for misuse. If a Nacos instance — or any configuration server — was ever internet-accessible or ran an unpatched version, every credential that passed through it should be considered potentially compromised and rotated accordingly. This is precisely the use case that secrets management tooling is designed to address: keeping credentials out of flat configuration files in the first place, and enforcing rotation policies that limit the window of exposure.

Patch velocity matters, even for “old” CVEs. CVE-2021-29441 is a five-year-old vulnerability. Its continued usefulness to attackers in 2026 reflects an enduring gap between disclosure and remediation across many organizations, particularly for infrastructure components that are less visible than front-end applications.

Access granted through a webshell is functionally privileged access. Once a webshell is running on a server, the attacker can read files, execute commands, and move laterally — capabilities that closely mirror what a privileged administrator account would provide. Detecting unexpected processes, unusual file patterns, or anomalous network connections from web servers should be part of any organization’s ongoing monitoring posture, not just a post-incident exercise.

Unpatched plugin ecosystems are an access-brokerage supply chain. The fact that a crew can build a sustainable business around automated exploitation of known, public CVEs in popular plugins — then resell that access — means the downstream risk extends beyond the compromised site itself. If a web server contains application credentials, session tokens, or API keys (and most production servers do), a webshell on that server is a credential-theft event, not merely a website defacement.

Reporting: Source