Mass CMS campaign turns unpatched plugins into webshells

The most useful thing in this week's alert from Australia's cyber agency is not any one bug. It is the shape of the target list. Sixteen or so known flaws, almost all of them in third-party WordPress, Joomla and Craft plugins, are being scanned for and exploited at scale to plant webshells. None of them are new. Every one already has a patch. The campaign works anyway, because the thing it exploits is not a vulnerability so much as a habit: the plugin you installed two years ago, stopped thinking about, and never wired into a patch cadence.

On July 11 the Australian Signals Directorate, through its Australian Cyber Security Centre (ACSC), warned of a large-scale campaign scanning websites and deploying webshells through content management system flaws, with many small and medium Australian businesses already hit. Security Affairs reported the same alert and the underlying pattern: most of the flaws let an unauthenticated visitor write a file to the server, run code on the host, coerce the server into making requests on the attacker's behalf, or trip an unsafe deserialization path, and every one of them is public and already fixed. Victims are the sites that simply had not applied the update.

The list is a plugin problem, not a CMS problem

Read the named CVEs together and one thing jumps out. The core content platforms are barely the story. Twelve of the entries are WordPress plugins, and the standalone-CMS entries (Craft, MaxSite, MetInfo, and the JCE editor on Joomla) are add-ons or components rather than the base install patched on a normal release train. If your mental model of "keeping the site updated" is the core CMS auto-updating itself, this campaign sails straight past it. The reachable attack surface is the plugin supply you accumulated, and most operators cannot name every plugin running on their own site, let alone its version.

The classes matter for triage. Unauthenticated file upload and unauthenticated RCE are the ones to fear here, because they need no account, no phishing, and no chain: a single crafted request drops a file the attacker can then execute. That is why webshells are the payload of choice. Once one lands, the ACSC alert notes it gives remote control of the server: harvesting credentials from site users, serving malware to visitors, and moving laterally into whatever the web host can reach.

We have been covering this backlog one bug at a time

None of these individual flaws would have made a headline on their own, and several of them we wrote up exactly that way. The JCE unauthenticated RCE on Joomla (CVE-2026-48907) is on this list. So is the same shape of bug we documented in Super Forms and the account-takeover flaw in the Branda plugin, and the Craft CMS template-injection line we traced through Formie. Each looked like a single-plugin story at the time. What the ACSC alert names is the industrial version: a scanner that does not care which of the sixteen it finds, only that it finds one. The severity of any single CVE was never the operative number. The aggregate reachability across a long tail of plugins is.

Patching is necessary and structurally too slow

The advice everyone will publish this week is "apply the updates," and you should. But treat it as the floor, not the ceiling, because the timeline no longer favors the defender. Per the Five Eyes agencies, AI is shortening the gap between a flaw going public and its mass exploitation, sometimes to a matter of days. When that window is measured in days, "we will pick it up in the next maintenance window" is not a patch policy, it is the exposure. You cannot schedule your way ahead of an automated scanner.

The claim that follows from that is uncomfortable but simple. If exploitation of a public flaw can beat your patch cycle, then the control that actually protects you is not the patch, it is knowing the moment a webshell lands. That is a monitoring problem, and it is one you can win even on the plugins you have not patched yet, because a webshell has to touch the file system and the web server has to do something it never normally does.

Watch the web root, not the plugin inventory

The highest-signal detections for this campaign do not depend on knowing which CVE hit you. Watch for the effects a webshell cannot avoid producing:

• New or modified executable files under the web root, especially inside plugin, upload, or cache directories that should never receive attacker-written code. File-integrity monitoring on those paths flags the drop even when the exploited plugin is one you had not gotten to. This is the single control the ACSC alert leans on hardest.
• A web server process spawning a shell or system command. Your web server serving PHP has no legitimate reason to launch sh, bash, or whoami. A child process off the web daemon is one of the cleanest webshell tells there is.
• Anomalous POST requests to plugin or upload endpoints, particularly unauthenticated writes to paths tied to the plugins above. The requests will be in your access logs before the webshell is ever used.

ACSC's own hardening list points the same direction: make web directories read-only where the application allows it, block outbound connections the web tier does not need, and restore from a known-clean backup rather than trying to clean a compromised host in place. All of that is standard, and all of it assumes you find out you were hit, which loops back to the detection above.

This is the part a managed detection layer earns its keep on. Continuous file-integrity monitoring on the web root, tuned so a new file in an upload directory pages a human, turns "a plugin we forgot about got popped" from a breach you discover months later into an alert you act on the same hour. Pair it with vulnerability detection that inventories the plugin versions actually installed, and you close both ends: what is exposed, and whether anyone has walked through it yet.

The campaign will not stop when this alert scrolls off the front page. The economics are too good: an automated scanner, a bottomless supply of unpatched plugins, and a webshell that pays out in credentials, malware distribution, and a foothold. Assume your site is on the scan list, because it is. The question the alert is really asking is whether you would know within an hour of the first file landing.