ACSC Warns of Large-Scale CMS Exploitation Campaign Deploying Webshells on Vulnerable Websites

The Australian Signals Directorate’s Australian Cyber Security Centre has warned that attackers are exploiting known vulnerabilities in content management systems and plugins to deploy webshells on websites worldwide, including sites operated by Australian small and medium-sized businesses.

The ASD’s ACSC alert says the campaign targets public CMS vulnerabilities that allow unauthenticated file upload, remote code execution, server-side request forgery, or deserialisation. Once attackers gain access, they drop webshells that let them remotely control the web server.

Website owners should check their CMS platforms, themes, plugins, and web directories immediately. A compromised site can be used to steal credentials, host malware, deface pages, scam visitors, or create a pathway into a wider business network.

What ACSC says is happening

The campaign does not depend on one CMS or one new zero-day flaw. Instead, attackers are scanning broadly for websites that still run vulnerable software with known public fixes.

ACSC says malicious actors are actively looking for opportunities to place webshells on exposed servers. A webshell is a malicious script or file that gives an attacker remote access through the web server itself.

That access can look like normal web traffic, which makes detection harder. The older CISA webshell guidance warns that webshells can give attackers unauthorized access and may lead to broader network compromise.

Vulnerable CMS products and plugins named in the alert

ACSC listed 17 CMS products and plugins being exploited. Most are WordPress plugins, but the campaign also targets Craft CMS, MaxSite CMS, MetInfo CMS, and Joomla JCE.

The important point for administrators is that these are known vulnerabilities. In many cases, attackers are taking advantage of sites that have not applied available updates or disabled vulnerable components.

The target list includes the following software and CVEs:

Software or plugin	Platform	CVE listed by ACSC
Simple File List	WordPress	CVE-2025-34085 / CVE-2020-36847
WavePlayer	WordPress	CVE-2025-12057
BerqWP	WordPress	CVE-2025-7443
WPBookit	WordPress	CVE-2025-7852
Ninja Forms	WordPress	CVE-2026-0740
ThemeREX Addons	WordPress	CVE-2026-1969
Breeze Cache	WordPress	CVE-2026-3844
pay-uz	WordPress	CVE-2026-31843
ACF Extended	WordPress	CVE-2025-13486
Sneeit Framework	WordPress-related framework	CVE-2025-6389
WPvivid Backup	WordPress	CVE-2026-1357
Gravity Forms	WordPress	CVE-2025-12352
GutenKit / Hunk Companion	WordPress	Likely CVE-2024-9234
Craft CMS	CMS	CVE-2025-32432
MaxSite CMS	CMS	CVE-2026-3395
MetInfo CMS	CMS	CVE-2026-29014
Joomla JCE	Joomla extension	CVE-2026-48907

Why webshells create a serious risk

A webshell gives attackers a hidden command path into a compromised server. From there, they can browse files, upload malware, run commands, modify pages, steal data, or keep access after the original vulnerability has been patched.

That persistence is why website owners should not treat webshell removal as a simple cleanup task. If a webshell exists, the server should be treated as compromised until logs, files, credentials, and network activity have been reviewed.

ACSC says compromised web servers may be used for website defacement, disruption, credential capture, additional malware uploads, scams against legitimate visitors, or broader network compromise.

How attackers are getting in

The exploited flaws fall into several high-risk categories. Each one can give attackers a path to place or run code on a web server if the CMS or plugin remains unpatched.

• Unauthenticated file upload can let attackers upload a malicious script without logging in.
• Remote code execution can let attackers run commands on the server.
• Server-side request forgery can make the server send attacker-controlled requests.
• Unsafe deserialisation can let attackers manipulate application logic and execute code.

The breadth of the target list suggests attackers are using automated scanning across many CMS ecosystems. They are not waiting for one perfect target. They are looking for any site that still exposes one of the listed weaknesses.

AI is shrinking the patching window

ACSC tied the campaign to a broader warning about faster exploitation. The agency pointed to a Five Eyes cyber security agencies statement that warns AI is accelerating the speed, scale, and sophistication of cyber threats.

That warning matters for CMS security because many website owners still patch plugins slowly. Attackers can now scan, test, and exploit public vulnerabilities faster, which leaves less time between disclosure and real-world compromise.

The practical lesson is direct: internet-facing CMS software and plugins need rapid patching, not occasional maintenance. For widely exploited vulnerabilities, disabling the affected plugin until a fix is applied may be safer than leaving it active.

Immediate checks for website owners

Website owners should start by identifying whether they use any of the listed CMS products or plugins. They should then check versions, patch status, recent file changes, and logs for suspicious access attempts.

Teams should inspect plugin folders, upload directories, theme directories, and other writable web paths. Suspicious files may use familiar extensions such as PHP, ASP, JSP, or aspx, but attackers can also disguise them with misleading names.

Useful checks include:

1. Review all installed CMS plugins, extensions, themes, and versions.
2. Patch affected CMS software and plugins immediately.
3. Disable vulnerable plugins if a patch cannot be applied right away.
4. Search web directories for recently created or modified files.
5. Look for unexpected files inside plugin, theme, upload, cache, and temporary folders.
6. Review web access logs for unusual GET or POST requests to unknown file paths.
7. Check whether the web server spawned unexpected child processes.

What to do if a webshell is found

If a webshell is found, administrators should not only delete the file and bring the site back online. The attacker may have created another backdoor, stolen credentials, added accounts, modified content, or moved deeper into the network.

The ACSC guidance recommends isolating affected servers, auditing authentication and network logs, tracing the initial exploit path, removing persistence mechanisms, patching the vulnerable software, and restoring from a recent known-good backup when compromise is confirmed.

Credential rotation should also be part of the response. CMS admin passwords, database credentials, FTP or SFTP accounts, API keys, hosting control-panel accounts, and related service credentials may have been exposed.

Response stage	Action	Reason
Containment	Isolate the affected web server	Stops further attacker access while the investigation continues
Investigation	Review web, authentication, and firewall logs	Helps identify the exploit path and possible lateral movement
Eradication	Remove webshells and persistence mechanisms	Prevents attackers from regaining access
Remediation	Patch the vulnerable CMS or plugin	Prevents reinfection through the same flaw
Recovery	Restore from a known-good backup if needed	Reduces the risk of leaving hidden attacker changes behind
Hardening	Rotate credentials and restrict server permissions	Limits follow-on attacks after the compromise

How to reduce future CMS compromise risk

Most of the defensive steps are basic, but ACSC says they have become more urgent. Website owners should reduce the number of exposed plugins, keep software current, and avoid leaving abandoned CMS components installed.

The webshell threat guidance also recommends patching public-facing servers, reviewing logs, using file integrity monitoring, limiting permissions, and looking for unexpected files or network connections.

Hardening steps include:

1. Remove plugins, extensions, and themes that are no longer used.
2. Enable automatic security updates when rollback risk is manageable.
3. Make web directories read-only where possible.
4. Block execution from upload and cache directories.
5. Use file integrity monitoring to detect unexpected changes.
6. Limit which server-side functions and binaries the web process can execute.
7. Segment internet-facing websites from internal business systems.
8. Use application control to restrict unexpected child processes from the web server.

Why small businesses are exposed

Small and medium-sized businesses often rely on CMS plugins for booking, forms, backups, caching, media players, payments, and page-building features. Those plugins can become the weakest point if they are installed and then forgotten.

Many businesses also outsource website maintenance, which can create unclear responsibility for patching and monitoring. If a hosting provider or web agency manages the site, business owners should ask whether the affected products are present and whether logs show suspicious activity.

The Five Eyes statement urges leaders to reduce attack surfaces, accelerate patching, address legacy systems, strengthen access controls, and prepare for incidents before they happen. That advice applies directly to public-facing CMS websites.

FAQ