# Global CMS Exploitation Campaign Hits Australian Businesses: ACSC Warns of Mass Webshell Deployments


The Australian Cyber Security Centre (ACSC) has issued a critical alert about an escalating, large-scale exploitation campaign targeting vulnerable content management systems worldwide, with significant impact already documented across Australian small and medium-sized businesses. The coordinated effort leverages known and newly discovered vulnerabilities in WordPress plugins, Joomla extensions, and other CMS platforms to deploy persistent webshells that grant attackers long-term access to compromised websites.


Webshells—malicious scripts uploaded to compromised servers—enable threat actors to maintain backdoor access, exfiltrate credentials, inject additional malware, and potentially pivot deeper into victim networks. The campaign underscores a critical gap in web application security for organizations that rely on third-party CMS platforms and their ecosystem of plugins.


## The Threat: Mass Exploitation at Scale


The ACSC describes the campaign as a "large-scale exploitation campaign" that is actively scanning websites globally to identify vulnerable CMS installations. Once a suitable target is located, attackers deploy webshells designed to persist even after initial patches are applied, creating a lasting foothold for future attacks.


The scope is substantial. The ACSC identified active exploitation of at least 16 distinct vulnerabilities across multiple platforms:


  • WordPress plugins (11 CVEs identified):
  • - Simple File List (CVE-2025-34085, CVE-2020-36847)

    - WavePlayer (CVE-2025-12057)

    - BerqWP (CVE-2025-7443)

    - WPBookit (CVE-2025-7852)

    - Ninja Forms (CVE-2026-0740)

    - ThemeREX Addons (CVE-2026-1969)

    - Breeze Cache (CVE-2026-3844)

    - pay-uz (CVE-2026-31843)

    - ACF Extended (CVE-2025-13486)

    - WPvivid Backup (CVE-2026-1357)

    - Gravity Forms (CVE-2025-12352)

    - GutenKit/Hunk Companion (likely CVE-2024-9234)


  • Other CMS platforms: Craft CMS (CVE-2025-32432), MaxSite CMS (CVE-2026-3395), MetInfo CMS (CVE-2026-29014), and Joomla JCE (CVE-2026-48907)

  • The campaign's breadth—spanning multiple CMS ecosystems and dozens of individual plugins—suggests either coordinated threat actors or an automated exploitation framework capable of indiscriminately scanning and targeting vulnerable installations.


    ## Background and Context: Why SMBs Are Vulnerable


    Small and medium-sized Australian businesses have reportedly been "impacted" at scale, according to the ACSC. This demographic represents a particularly attractive target: SMBs often lack dedicated security teams, operate with limited IT budgets, and may not prioritize rapid patching cycles for CMS components.


    The vulnerability landscape is fragmented. Unlike monolithic applications maintained by a single vendor, WordPress alone runs on approximately 43% of all websites globally, with an ecosystem of thousands of third-party plugins. Each plugin represents a potential attack surface. When vulnerabilities are disclosed—particularly in widely used plugins—the lag between disclosure and patching creates a critical exploitation window.


    The reliance on plugin marketplaces (WordPress.org, WooCommerce, etc.) adds organizational overhead: administrators must monitor multiple sources for security updates and manually patch each component, or rely on automatic updates that may introduce compatibility issues.


    ## Technical Details: How the Campaign Works


    Attack vector: The campaign leverages unauthenticated remote code execution (RCE) vulnerabilities in CMS plugins, many of which allow file uploads, parameter injection, or direct script execution without proper validation.


    Exploitation process:

    1. Threat actors scan the web using automated tools, identifying installations of vulnerable CMS platforms and plugins

    2. When a vulnerable installation is discovered, the attacker exploits the vulnerability to upload a webshell—typically a small PHP or similar script that allows remote code execution

    3. The webshell grants the attacker persistent access to the compromised server

    4. From this foothold, attackers can:

    - Exfiltrate sensitive data (customer information, credentials, database contents)

    - Deploy additional malware (ransomware, cryptominers, advanced persistent threats)

    - Modify website content for defacement or SEO poisoning

    - Redirect visitors to malicious sites

    - Move laterally into the broader network, targeting other systems


    AI acceleration: The ACSC notes the campaign "might be supported by AI," which can accelerate vulnerability scanning, exploit adaptation, and payload generation. AI-assisted tools can rapidly test multiple exploit variations, identifying which specific plugin versions are vulnerable and deploying tailored payloads at machine speed.


    ## Implications for Organizations


    Immediate risk: Any organization running WordPress, Joomla, Craft CMS, or related platforms is potentially exposed if plugins are not fully patched. The public CVE disclosures mean that exploit code is likely already available to attackers; the window between patch availability and deployment narrows with each day of delay.


    Supply chain complexity: Organizations that don't directly manage their CMS—such as those relying on managed hosting providers—may have limited visibility into patch status. This creates a blind spot where vulnerabilities could persist undetected.


    Business continuity: Webshell deployments don't necessarily trigger immediate outages, allowing attackers to maintain covert access. Weeks or months may pass before a breach is discovered, during which attackers can harvest credentials, access payment systems, or establish deeper network footholds.


    ## Recommendations: Hardening CMS Deployments


    The ACSC provides a layered defense strategy:


    | Control | Purpose |

    |---------|---------|

    | Apply security updates immediately | Patch all CMS, themes, and plugins as soon as updates become available |

    | Remove unused components | Uninstall inactive plugins and themes to reduce attack surface |

    | Enable automatic updates | Where compatibility risks are acceptable, enable automatic patching |

    | Configure read-only directories | Make web directories read-only where file uploads aren't required |

    | Monitor file creation | Alert on unexpected file creation in web-accessible directories |

    | Restrict directory access | Limit access to sensitive directories (wp-admin, plugins, themes) |

    | Block unexpected processes | Monitor and block child process spawning from web server processes |


    Beyond the basics: Organizations should also consider Web Application Firewalls (WAF) to block exploitation attempts, maintain regular backups to enable rapid recovery, and implement intrusion detection signatures for known webshell patterns.


    ---


    ## HackWire Analysis


    This campaign illustrates a fundamental flaw in the WordPress ecosystem's security model: the responsibility for patching has been distributed across thousands of plugin developers with wildly varying security practices and response times. While WordPress.org enforces some standards, many plugins remain unmaintained—some for years—yet remain active on millions of sites.


    The sheer number of affected plugins (16+ identified CVEs) suggests attackers aren't targeting sophisticated zero-days; they're exploiting *known* vulnerabilities at scale, betting that many site administrators won't patch within the exploitation window. This is a volume-and-efficiency game, not a precision surgical strike.


    What's notably absent from mainstream coverage: this campaign likely succeeds quietly. Webshells don't generate visible damage immediately. An attacker's presence on a compromised WordPress site might go unnoticed for months while credentials are harvested, data is exfiltrated, or the compromised site is used as a jumping-off point for lateral network movement. The ACSC's alert, issued proactively, suggests Australian authorities detected the campaign through threat intelligence rather than incident reports—meaning many victims may not yet know they've been compromised.


    For defenders, the lesson is uncomfortable: patching velocity matters more than perfection. Organizations that can't deploy security updates within 48–72 hours of disclosure shouldn't rely solely on CMS platforms with expansive third-party ecosystems. Alternatively, implementing a WAF with virtual patching capabilities, coupled with automated vulnerability scanning and alert systems, can bridge the gap. Waiting for site administrators to manually apply patches has repeatedly proven insufficient.


    The involvement of AI in scaling exploitation adds urgency. As automated scanning and payload generation improve, the window between disclosure and widespread compromise shrinks further. — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)