A cybercrime crew running a mass-site-backdooring operation accidentally left their command server wide open on the internet for three weeks – and security researchers walked right in. The exposed server, now tracked as WP-SHELLSTORM, held the crew's entire toolkit: 800 MB of webshells, exploit scripts, automated scanner tools, target lists naming more than 1.4 million websites, and a full command history that documented how the operation worked from the inside. Researchers from SOCRadar (who published July 9, 2026) and Ctrl-Alt-Intel (who found it June 22 via Hunt.io) both analyzed the same exposed server. The confirmed compromise count is far smaller than the 1.4 million headline – 25,195 sites validated by Ctrl-Alt-Intel, roughly 5,700 active webshells counted by SOCRadar – but the operation targeted real plugins that real site owners run today, and the attacker's own logs tell you exactly which ones worked.

What the Operation Is

WP-SHELLSTORM is what SOCRadar calls a webshell access brokerage: a crew that breaks into websites at industrial scale, plants a hidden backdoor (a “webshell”) on each, and sells that access to other criminals. Think of it as break-in-as-a-service – the crew doesn't necessarily exploit the sites themselves; they package and resell the access.

The attack flow is methodical:

  1. Pull massive target lists from FOFA, a Chinese internet-scan search engine (similar to Shodan but requiring a Chinese phone number to register).
  2. Run automated exploit scripts against every target in the list, firing known plugin vulnerabilities.
  3. On vulnerable sites, upload down.php – a heavily obfuscated, four-layer-deep webshell derived from the open-source Chinese BestShell project.
  4. Install VShell, a stealthy backdoor that disguises its process as [kworker/0:2] to blend in with the Linux kernel worker threads in a process listing.
  5. Move on. The crew ran this against hundreds of thousands of targets simultaneously.

The entire toolchain consisted of 27 known, patched CVEs – no zero-days needed. Public exploits, automated scanning, and a target list a million lines long were enough to compromise sites at scale.

How the operation got caught

The crew operator started a Python web server to move files between their own machines and left it running – without a password – on a US-based rented server at 137.175.93[.]126 for 22 days. Ctrl-Alt-Intel found the open directory on Hunt.io's open-directory platform on June 22. SOCRadar independently found it and published their detailed analysis on July 9. When the crew realized they'd been spotted (sometime between July 2 and July 4, based on log deletions), they started deleting evidence. Three weeks too late.

Why It Matters

  • Scale with no zero-days. The entire operation ran on publicly known, patchable vulnerabilities. If your plugins are out of date, you're in the target pool.
  • Access gets resold. A webshell on your server doesn't mean one bad actor. Access gets sold multiple times – you can end up with several unrelated criminal actors on the same server.
  • The backdoor is stealthy. VShell disguises itself as a Linux kernel thread ([kworker/0:2]). Standard ps output looks clean. You need to check /proc/<pid>/exe to spot it.
  • The same toolchain was used for corporate espionage. Before pivoting to mass WordPress backdooring, the same crew spent May 2026 extracting cloud credentials (AWS, Alibaba Cloud, Oracle, Tencent, DigitalOcean) and database passwords from corporate Java systems via unpatched Nacos servers.
  • The SNOWLIGHT→VShell chain has prior attribution. In April 2025, Sysdig linked this exact toolchain to UNC5174, a suspected Chinese state-connected threat actor. VShell is common enough in Chinese-speaking criminal forums that individual actor attribution remains uncertain, but the operational pattern is documented.

Am I Affected?

You may be exposed if any of the following apply:

WordPress sites:

  • You run Breeze Cache (by Cloudways) with the non-default “Host Files Locally – Gravatars” setting ON. CVE-2026-3844, fixed in Breeze 2.4.5. This was the single most productive exploit in the campaign – 45,000 targets, 17,000 confirmed shells.
  • You have ThemeREX Addons installed (CVE-2026-1969) – 3,378 shells from 46,600 targets.
  • You have Ninja Forms with the file-upload add-on (CVE-2026-0740).
  • You have WP File Manager (CVE-2020-25213) – an old critical-severity unauthenticated RCE that is still widely unpatched.
  • You have Simple File List (valid ID: CVE-2020-36847).
  • You have Custom CSS JS PHP (CVE-2026-6433), BerqWP (CVE-2025-7443), WavePlayer (CVE-2025-12057), or WPBookit (CVE-2025-7852).

Joomla sites:

  • Your Joomla Content Editor (JCE) extension is below 2.9.99.5. CVE-2026-48907, CVSS 10.0, actively exploited and on CISA's Known Exploited Vulnerabilities list. The crew targeted over 560,000 Joomla domains but landed on only 77 – an extremely low hit rate, suggesting most Joomla admins have already patched this one.

Java/application servers:

  • You run a self-hosted Nacos configuration server (CVE-2021-29441) with authentication disabled or exposed to the internet. Nacos with auth off lets an attacker skip the login entirely by forging a single HTTP header. This is how the crew exfiltrated corporate cloud credentials in May 2026.
  • You have unauthenticated XXL-Job executor endpoints or Spring Boot /actuator/heapdump enabled in production.

What to Do About It

1. Update vulnerable WordPress plugins immediately

# From WordPress admin: Plugins → Updates → Select All → Update
# Or via WP-CLI:
wp plugin update --all

Specifically check and update (or remove if unused):

  • Breeze Cache → update to 2.4.5 or later; if the “Host Files Locally – Gravatars” setting is off, you were never at risk from this campaign.
  • WP File Manager → ensure you are on a version that patches CVE-2020-25213 (2.9.4 or later); better yet, audit whether you need this plugin at all.
  • ThemeREX Addons → update to the latest version that patches CVE-2026-1969.
  • All other plugins in the list above → update to current.

2. Update Joomla JCE (even if you think you already patched)

JCE 2.9.99.5 patches CVE-2026-48907. Because this is on CISA's KEV list (actively exploited in the wild), treat it as urgent even if your Joomla site wasn't in the campaign's target list.

3. Secure or remove Nacos, XXL-Job, and Spring Boot actuators

# Nacos: turn on authentication
# In nacos-server/conf/application.properties:
nacos.core.auth.enabled=true

# Immediately rotate ALL credentials stored in Nacos if the instance was ever
# internet-facing without auth - cloud keys, DB passwords, API keys, everything.

# Spring Boot: disable heapdump in production
# application.properties:
management.endpoint.heapdump.enabled=false
management.endpoints.web.exposure.include=health,info

4. Hunt for the crew's webshells and backdoor

# Search for the crew's known webshell filename patterns:
find /var/www -name "*.bd.php" -o -name "*.wp-log.php" -o -name ".brq-*.php" 2>/dev/null

# Check for the VShell process masquerading as a kernel thread.
# A real kworker thread has no exe link, no cmdline, and no network sockets:
for pid in /proc/[0-9]*; do
  comm=$(cat $pid/comm 2>/dev/null)
  if [[ "$comm" =~ ^kworker ]]; then
    exe=$(readlink $pid/exe 2>/dev/null)
    if [[ -n "$exe" ]]; then
      echo "SUSPICIOUS: $pid ($comm) -> $exe"
    fi
  fi
done

# Check for network connections from kworker-named processes:
ss -tlnp | grep -i kworker

5. Block known malicious infrastructure

Add these to your firewall's block list or WAF rules:

  • 137.175.93[.]126 – the exposed C2 server
  • 43.108.17[.]80 – secondary infrastructure
  • Domain: xs.xxooonline[.]eu[.]cc – C2 domain

6. Check wp-config.php and server credentials

If you find evidence of compromise, assume your wp-config.php credentials, database passwords, and any API keys stored in the WordPress database or file system have been exfiltrated. Rotate them all.

Quick-Win Checklist

  • Run wp plugin update --all or update plugins from the WordPress admin dashboard.
  • Confirm Breeze Cache is updated to 2.4.5+ (or verify the “Host Files Locally – Gravatars” setting is off).
  • Update Joomla JCE to 2.9.99.5+ if you run Joomla.
  • Audit WP File Manager – update or remove it.
  • Search the server for .bd.php, .wp-log.php, .brq-*.php webshell patterns.
  • Check for impostor [kworker] processes (should have no /proc/<pid>/exe).
  • Block 137.175.93[.]126 and 43.108.17[.]80 at the firewall.
  • Disable the Nacos authentication bypass if running Nacos (set nacos.core.auth.enabled=true).
  • Rotate credentials if any exposure is found (DB passwords, cloud keys, API keys).
  • Enable file-integrity monitoring or a security plugin (Wordfence, iThemes Security) if not already running one.

Sources