WordPress Webshell Attack WP-SHELLSTORM

10

If your organisation runs a WordPress or Joomla site, and something like a quarter of the web does, a recently exposed criminal server hands you a rare thing. It’s a concrete list of what to check this week. Researchers named the operation behind it WP-SHELLSTORM. The crew backdoored thousands of sites using plugin bugs that already had patches. Here’s what happened, and what this wordpress webshell attack means for your own checklist.

Inside the wordpress webshell attack

SOCRadar’s threat intelligence team found an unsecured server on 11 June 2026. So it had no password at all, reachable by anyone who found it. A second research group, Ctrl-Alt-Intel, found the same open folder independently through Hunt.io. The operator had left a basic Python file server running for 22 days. They used it to move tools around, and once it was working, simply never locked it down.

That folder held roughly 800MB across 434 files. Inside were webshells, scanner scripts, raw command history and target lists covering 1.4 million domains, and one single list named 587,034 Joomla sites. Of those targets, researchers found evidence of actual compromise on 25,195 sites. They also identified more than 5,700 webshells still active at the time of analysis, so the working total was far smaller than the target list, though still large.

The five bugs doing most of the damage

The toolkit chained together 27 known vulnerabilities. But a handful of them accounted for almost all the confirmed backdoors. In order of effectiveness:

• Breeze caching plugin, CVE-2026-3844: over 45,000 sites targeted, more than 17,000 backdoored. It only works where the “Host Files Locally – Gravatars” option is switched on, so many sites running Breeze were never at risk.
• Joomla JCE editor, CVE-2026-48907: serious enough that CISA added it to its Known Exploited Vulnerabilities catalogue.
• ThemeREX Addons, CVE-2026-1969: an older bug, since it stays live on sites that never removed the plugin after switching themes.
• Simple File List: a long-patched flaw, still working because updates were never applied.
• Apache Nacos, CVE-2021-29441: used against corporate configuration servers, not public websites. This was a separate arm of the same operation. It stole 613 configuration files, including cloud provider credentials, from nine companies.

Every successful wordpress webshell attack in this campaign dropped a payload called down.php. It was wrapped in four scrambled layers and built on the public BestShell code. Some victims also picked up VShell, a backdoor that disguises its process as “[kworker/0:2]” so it looks like ordinary kernel housekeeping in a process list.

A checklist for this week

None of this needed a zero-day, because every plugin involved had a fix available before the campaign used it. That’s the actionable part for any IT manager reading this, so work through the following once your plugin list is in front of you:

1. Inventory your plugins. List every plugin and theme on every WordPress or Joomla site your business runs. Include the ones nobody remembers installing. A vulnerability assessment against that list will confirm which ones are actually exposed before you start patching.
2. Patch or remove. Update Breeze, ThemeREX Addons, Simple File List and any Joomla JCE installs immediately. If a plugin is not in active use, remove it. Don’t leave it dormant.
3. Hunt for existing backdoors. Search file systems for suspicious filenames such as .bd.php, .wp-log.php, .sd.php, .leo__.php and .nf-log.php. Check running processes too, for anything named like [kworker/X:Y] that doesn’t match your system’s genuine kernel workers.
4. Block known infrastructure. Add the exposed operator server, 137.175.93[.]126, to your blocklists. Add any other IOCs your WAF or hosting provider publishes for this campaign as well.
5. Rotate credentials where Nacos or similar configuration servers are in play. If your business uses Apache Nacos, upgrade past 2.2.1, enable authentication, and rotate anything stored in its configuration files.
6. Put a WAF in front of anything you can’t patch immediately. A firewall configuration review buys time between disclosure and patching. That’s exactly the window this crew exploited.

Why the inventory step gets skipped

Most businesses that run WordPress or Joomla did not build the site in-house. They don’t have a standing relationship with whoever configured it. A plugin gets added to solve one problem, an old form builder or a caching tool nobody remembers picking, and then it sits there untouched because nobody owns updating it. That’s exactly the gap WP-SHELLSTORM’s automated scanners were built to find. The crew wasn’t choosing targets by hand. They were sweeping FOFA’s results for whatever plugin version still had a known bug attached to it.

If you don’t have a single list of every plugin and theme running across your organisation’s websites, building one is the first item on this checklist, not the last. You cannot patch what you haven’t inventoried. An external attacker with a scanner will find the gap faster than an internal team without one, and that gap is how a wordpress webshell attack like this one gets a foothold.

The bigger point

WP-SHELLSTORM wasn’t targeting anyone in particular, so treating this as someone else’s problem is a mistake. It was building an inventory of footholds to sell on, and a low-traffic company site is just as useful for that purpose as a high-profile one. Patch cadence on the plugins nobody thinks about is what stood between these businesses and a wordpress webshell attack. It’s the same lesson this site drew from the OptinMonster supply-chain backdoor, which hit over a million WordPress sites through a trusted plugin update