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

Exploitation surface: plugins, uploads, RCE, SSRF

ACSC says attackers are scanning websites for vulnerable CMS platforms and plugins, then deploying webshells that provide remote access and control of compromised web servers. The reported vulnerability classes are the usual high-impact set: unauthenticated file upload, remote code execution, server-side request forgery, and unsafe deserialization.

WordPress is directly in scope. The plugin list cited in reporting includes Simple File List, WavePlayer, BerqWP, WPBookit, Ninja Forms, ThemeREX Addons, Breeze Cache, pay-uz, ACF Extended, Sneeit Framework, WPvivid Backup, Gravity Forms, and GutenKit/Hunk Companion. The same campaign also references Craft CMS, MaxSite CMS, MetInfo CMS, and Joomla JCE.

That breadth matters operationally. We should not model this as a WordPress-core-only problem or as a single vendor failure. The pattern is automated discovery of known vulnerable software, followed by file-system persistence. Do not treat this as content hygiene or brand-health work; whether the site publishes plugin documentation, booking pages, or modern wellness content, the artifact to investigate is server-side unauthorized code.

Required checks: file system, access logs, persistence

ACSC’s immediate guidance is narrow and useful: inspect CMS environments for webshells and abnormal file changes. Then review web access logs for suspicious GET or POST requests targeting webshell paths. Historical log review is required to identify the initial exploitation activity, not just the last request that touched the shell.

For WordPress teams, the practical sequence is:

1. Inventory active themes, plugins, mu-plugins, and any writable web directories.

2. Compare the live file tree against a known-good baseline or clean deployment source.

3. Review access logs for unusual GET or POST traffic to recently created or modified files.

4. Review authentication and network logs for signs of persistence or lateral movement.

5. Patch vulnerable systems before restoring service.

6. Restore from a recent known-good backup where compromise is suspected.

The key ACSC position is strict: any server with an identified webshell should be treated as compromised. Isolation comes before cosmetic cleanup. Deleting the visible shell without auditing network logs, authentication logs, and file modifications leaves the incident open.

Mitigation baseline: reduce writable code paths

The campaign is reported to use already-known vulnerabilities, including issues with public patches available for many targets. That makes patch latency the primary bottleneck. ACSC recommends keeping website software and plugins updated, considering automatic patching where appropriate, and disabling plugins with actively exploited vulnerabilities until mitigations are applied.

Hardening should focus on file creation and execution paths. ACSC also recommends restricting or monitoring file creation in web directories, limiting access to sensitive files and paths, monitoring for unexpected child processes spawned by web servers, and blocking unnecessary network communication between internet-facing websites and internal corporate systems.

Minimum expected state after remediation:

• No unexplained files in CMS directories.
• No suspicious GET or POST requests to webshell-like paths in reviewed logs.
• Vulnerable plugins patched, mitigated, or disabled.
• Affected systems restored only from known-good backups.
• Network paths from the public web tier to internal systems reduced or blocked where unnecessary.
• Evidence reviewed for persistence and lateral movement before the site is returned to normal operation.

This is a containment problem first and a plugin maintenance problem second. Patch management prevents reinfection; it does not prove the existing host is clean.