Large-Scale CMS Exploitation Campaign Highlights the Risk of Unpatched Public-Facing Systems

ASD’s ACSC (Australian Signals Directorate’s Australian Cyber Security Centre) published a critical alert about a large-scale exploitation campaign targeting CMS (Content Management System) platforms and extensions. The campaign abuses known vulnerabilities across different content management systems to deploy webshells on compromised web servers.

The topic matters because a public website is often treated as a separate marketing asset. In real environments, it may be part of broader infrastructure connected to contact forms, customer portals, integrations, databases, internal systems or cloud services.

When a CMS website is compromised, the risk is not limited to website defacement. Webshell access may allow attackers to execute commands remotely, steal data, distribute malware or attempt movement toward other systems.

What Is Happening

According to ACSC, the campaign targets various CMS platforms, plugins and extensions, including the WordPress ecosystem and standalone CMS solutions. Attackers are not relying on a single vulnerability. They are scanning public-facing websites and looking for systems running unpatched versions of affected components.

The abused weaknesses include several common categories:

• unauthenticated file upload;
• remote code execution;
• Server-Side Request Forgery (SSRF);
• unsafe deserialization;
• weak restrictions on executable files;
• insufficient controls over directories and plugins.

After successful exploitation, attackers deploy a webshell into the server file system. This provides a hidden remote-control channel that may remain active after the initial compromise.

What a Webshell Is and Why It Matters

A webshell is a malicious file or script placed on a web server that allows the attacker to execute commands through web access. It is often disguised as a legitimate file inside a website directory, plugin, theme, cache folder or upload area.

The risk is that a webshell does not always cause visible website changes. The page may look normal while the attacker uses the server to:

• steal configuration files;
• access databases;
• collect user data;
• add new administrative accounts;
• modify content;
• distribute malware;
• host phishing pages;
• proxy traffic;
• attempt access to internal systems.

A webshell should therefore be treated as evidence of a compromised environment, not as an isolated file that can simply be deleted.

Affected Platforms and Components

Public reporting lists a broad set of affected CMS components. These include WordPress plugins such as Simple File List, WavePlayer, BerqWP, WPBookit, Ninja Forms, ThemeREX Addons, Breeze Cache, pay-uz, ACF Extended, Sneeit Framework, WPvivid Backup, Gravity Forms and GutenKit or Hunk Companion.

The campaign also includes other platforms and extensions such as Craft CMS, MaxSite CMS, MetInfo CMS and Joomla JCE.

The exact list matters, but the more important point is the attack pattern. Attackers are not looking for one specific product. They are looking for any public-facing system with a known vulnerability, a public exploit or delayed patching.

This approach increases the likelihood of finding a vulnerable target, especially in organisations with many websites, old plugins, external agencies, legacy installations or no central process for web asset management.

Why This Matters for Organisations

CMS platforms often sit at the edge of the organisation. They are public, internet-facing and frequently maintained by different teams — marketing, external developers, hosting providers or IT.

This creates several risks:

• website ownership is not always clearly defined;
• plugins are added for functionality but not always reviewed for risk;
• old themes and extensions remain active;
• test or archive sites remain publicly accessible;
• backups are not always validated;
• logs are not always collected and analysed;
• the website may connect to internal systems or databases.

When compromised, a public website can be used as an entry point, malicious content infrastructure or a way to abuse trust in the brand.

How the Attack May Develop

A typical scenario includes several stages:

• scanning the internet for vulnerable CMS installations;
• identifying a specific platform, plugin or version;
• sending requests to a known vulnerability;
• uploading or creating a webshell;
• testing whether webshell access works;
• collecting configuration files and credentials;
• creating additional backdoor mechanisms;
• using the server for follow-on activity.

If the website is properly isolated, the impact may remain limited to the web server. If the server has access to internal networks, databases, admin panels or cloud credentials, the attack may extend beyond the website itself.

Recommended Actions

Organisations using CMS platforms should start by reviewing their public web assets.

Priority actions include:

• identify all CMS websites, including test, archive and campaign pages;
• check versions of CMS platforms, plugins, themes and extensions;
• remove unused plugins and themes;
• apply available patches for affected components;
• temporarily disable a component if a public vulnerability exists and patching cannot be completed immediately;
• review website directories for unusual files;
• inspect upload, cache, plugin and theme folders;
• look for scripts that do not match the normal website structure;
• review web access logs for requests to known webshell paths;
• check for unexpected processes spawned by the web server user;
• restrict script execution in upload directories;
• set web directories as read-only where possible;
• limit network connections between public websites and internal systems;
• review administrative accounts and reset passwords;
• inspect databases and configuration files for leaked credentials;
• restore only from a clean and validated backup.

If a webshell is found, the environment should be treated as compromised. Deleting the file is not enough. The initial compromise path must be identified, lateral movement must be checked, and all exploited vulnerabilities must be closed.

DIAMATIX Perspective

The campaign shows why public web systems need to be part of the overall risk picture. A CMS website is often the first system an attacker sees. If it runs unpatched plugins, weak segmentation and limited monitoring, it can become an accessible entry point.

For businesses and public sector organisations, this is a manageable risk if ownership is clear. It should be known who owns the website, who tracks vulnerabilities, who approves patches, who reviews logs and how the organisation responds to suspected compromise.

For cybersecurity providers, this is also a visibility issue. Webshell activity may be missed if monitoring is limited to endpoint or firewall events. Context is needed from web servers, file changes, processes, network connections, administrative actions and post-compromise behaviour.

DIAMATIX treats campaigns like this as an exposure management issue, not only as a web incident. Risk should be assessed based on where the system is located, what data it processes, what it connects to and what the impact of compromise would be.

This is especially important for organisations with many websites, regional structures, external agencies, old campaign pages or separate business units. In such environments, there are often assets that do not appear in the main IT inventory but remain public and reachable by attackers.

CISO Analysis

For CISOs, this campaign raises several practical questions.

The first area is ownership of public web assets. If the marketing website is maintained by an external agency, hosting provider or separate team, security responsibility must be clearly defined.

Key questions include:

• Do we have a complete list of public websites and CMS installations?
• Who is responsible for updating CMS platforms, plugins and themes?
• Is there a process to urgently disable a vulnerable plugin?
• Do we track vulnerabilities in website components?
• Are test and archive websites included in monitoring scope?

The second area is impact containment. Even if a webshell is deployed, the architecture should limit what the attacker can do.

Key questions include:

• Can the public web server access internal systems?
• Is there segmentation between the website, database and internal network?
• Which directories allow script execution?
• Are read-only controls applied to critical web directories?
• Do we monitor unexpected processes spawned by the web server user?

The third area is detection. A webshell may remain active for a long time if there is no file monitoring, log analysis and correlation between web activity and follow-on behaviour.

Key questions include:

• Do we collect web access logs and retain them long enough?
• Can the SOC detect requests to known webshell paths?
• Do we monitor file system changes on the website?
• Are unexpected outbound connections from the web server flagged?
• Can we connect a web request to later process execution?

The fourth area is response. If a webshell is found, deleting the file and updating the plugin is not enough. The organisation needs to understand what happened during the compromise window.

Key questions include:

• When was the webshell deployed?
• Which files were accessed or modified?
• Were new administrative accounts created?
• Were credentials exposed through configuration files?
• Is there evidence of lateral movement?
• Is restoration performed from a validated clean backup?

For CISOs, the operational takeaway is that CMS websites should not sit outside vulnerability management, monitoring and incident response processes. A public website may be a small asset from a business perspective, but a high-risk entry point from an attacker’s perspective.

What This Means for Your Environment

• This type of risk relies on known vulnerabilities, public-facing CMS systems and delayed patching.
• Detection depends on visibility into web servers, file changes, web access logs, unexpected processes and outbound connections.
• Response requires isolation of the affected server, webshell review, log analysis, credential rotation, vulnerability closure and restoration from a clean backup.

Key questions to review:

• Do you know all CMS websites your organisation maintains?
• Do you have a process to quickly update or disable vulnerable plugins?
• Can the public website access internal systems?
• Does the SOC have visibility into webshell activity?
• Are old campaign, test and archive websites reviewed?

Review the exposure of your public web systems

DIAMATIX can help review:

• public CMS websites, plugins and extensions;
• unpatched versions and known vulnerabilities;
• webshell indicators and suspicious file changes;
• web access logs and abnormal requests;
• connections between public websites and internal systems;
• response readiness for compromised web servers.

Request a public web exposure review with DIAMATIX

Trusted · Innovative · Vigilant

Sources

• ASD’s ACSC. Large-scale exploitation campaign targeting website content management systems (CMS).
• Australian Cyber Security Magazine. ACSC warns of large-scale campaign exploiting CMS vulnerabilities in Australia.
• Cyber Security News. ACSC Warns of Large-Scale CMS Exploitation Campaign Deploys Webshells on Vulnerable Websites.

This article is based on publicly available information as of July 2026.