Customer Experience · CMS security

Patch first, then plan

It is if it isn't patched. ASD's Australian Cyber Security Centre issued a critical alert on 9 July 2026 about attackers exploiting known, already-patched vulnerabilities in CMS software and plugins, including at many small to medium Australian businesses. Every WA organisation with a website should update its CMS and plugins, check for webshells and review access logs.

Key takeaways

  • On 9 July 2026, ASD's ACSC issued a critical alert about a large-scale campaign exploiting CMS software and plugins, with many small to medium-sized Australian businesses impacted.
  • Attackers scan websites for known vulnerabilities, then install webshells that give them remote access to and control of the web server.
  • The vulnerabilities being exploited are public and already have patches, so keeping your CMS and every plugin up to date is the first defence.
  • Platforms past the end of vendor support get no new security fixes, so their risk grows over time.
  • Check your CMS for webshells, review web access logs, and set web directories to read-only where you can.

What has the ACSC warned about?

On 9 July 2026, the Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC) issued a critical alert: a large-scale exploitation campaign is actively targeting website content management systems (CMS) globally, including in Australia, with many small to medium-sized Australian businesses impacted.

This is not a forecast or a theoretical risk assessment. The campaign is active. Attackers are scanning websites right now, hunting for known vulnerabilities in CMS software and plugins. When they find one, they deploy a webshell: persistent, hidden code that gives them ongoing remote access and control of the web server.

If your organisation runs a public-facing website, this alert is relevant to you.

How are attackers getting into CMS websites?

According to the alert, malicious actors are conducting systematic, automated scans of websites worldwide, targeting known vulnerabilities in CMS platforms and their associated plugins. The attack methods documented include:

  • Unauthenticated file upload vulnerabilities
  • Remote code execution exploits
  • Server-side request forgery (SSRF)
  • Deserialisation vulnerabilities

Once a vulnerability is identified and exploited, attackers deploy webshells: malicious scripts embedded directly in the web server. From there, the consequences can extend well beyond the website. The ACSC lists website defacement or disruption, capturing credentials entered by website users or other data stored on the server, uploading more malware to target and scam website users, and using the web server as a pathway into the broader network.

The ACSC alert is publicly available and worth reading in full: Large-scale exploitation campaign targeting website content management systems (CMS).

Which CMS platforms are affected?

The alert names the software being exploited, mostly WordPress plugins plus Craft CMS, Joomla JCE, MaxSite CMS and MetInfo CMS, but its lesson is not platform-specific. Whether you're running WordPress, Umbraco, Sitefinity, Drupal, Kentico, or any other CMS, the fundamental message is the same: unsupported, unpatched software increases your security risk.

Attackers aren't targeting particular brands. They're scanning for known, unpatched vulnerabilities, the kind that accumulate when software isn't updated, when plugins are left on old versions, or when a CMS platform has reached the end of its vendor support lifecycle.

The platform matters less than the maintenance discipline, and whether your CMS vendor is still shipping security fixes.

Why is end-of-life CMS software a bigger risk?

Most CMS platforms have a support lifecycle: a period during which the vendor actively ships security patches, fixes known vulnerabilities, and responds to newly discovered CVEs. When a platform reaches end of life (EOL), that support stops.

Running EOL CMS software creates a specific and growing risk:

  • Vulnerabilities discovered after the EOL date have no vendor fix available
  • Your internal IT team cannot patch what the vendor no longer patches
  • The attack surface doesn't stay static, it expands as new vulnerabilities are found and publicised
  • Attackers actively target EOL software precisely because the unpatched vulnerability inventory is known and growing

This is the same risk class the ACSC alert describes: known vulnerabilities left unpatched. And it's why EOL platform users should treat this alert as a prompt not just to audit their current patching status, but to understand whether they're building on a foundation that will continue to receive security support.

What does the ACSC recommend you do now?

The ACSC's core recommendation is to keep CMS software and plugins patched and up to date. That's the right starting point. Beyond that, the alert also recommends:

  • Configuring web directories as read-only to prevent webshell deployment
  • Inspecting your CMS for signs of webshell installation
  • Reviewing web access logs for suspicious activity and indicators of compromise

We've put together a short practical checklist below that covers the essentials. It takes about ten minutes to work through and gives you a clear picture of where your exposure sits.

Should the alert change your CMS platform plans?

The ACSC alert is a moment to audit, but it's also a useful prompt for a longer-term question: is your current CMS platform one you can rely on for security support over the next three to five years?

The shift happening in the market is meaningful here. Platforms that have moved to an evergreen model (continuous, automatic security updates rather than periodic major versions) structurally reduce the risk class this alert describes. There are no gaps between versions. There's no EOL date creating a cliff edge. Security is ongoing, not episodic.

That's not a reason to change platform based on one alert. But it is worth factoring into any platform review you're conducting this year.

Is there a quick way to check your CMS security?

We've put together a practical seven-point checklist for any organisation that wants to quickly assess their CMS security posture. It covers the basics the ACSC alert recommends, plus a few additional questions worth asking of your web team or digital agency.

Download the CMS Security Checklist

If you have questions about your organisation's specific situation, or want to understand what a platform review looks like in practice, our team is happy to have that conversation. No deck. No obligation.

About Dapth

Dapth is your Perth digital consultancy, building connected digital systems from websites and intranets to applications, software, ERP and AI tools. For more than 15 years we have helped WA businesses, government agencies and organisations unlock advantages like streamlined workflows, increased efficiency, cost savings, new revenue and more powerful marketing.

We start with your organisation, not the technology: your users, your operations and your objectives. Then we connect everything across four areas:

Not sure whether your CMS and plugins are patched and still supported? Talk to Dapth about what a platform review looks like for your website.

Talk to Dapth about your CMS

Frequently asked questions

What did the ACSC alert about CMS attacks say?

On 9 July 2026, ASD's ACSC published a critical alert about a large-scale campaign exploiting vulnerabilities in website content management systems globally, including in Australia, with many small to medium-sized businesses impacted. Attackers scan for vulnerabilities that allow unauthenticated file upload, remote code execution, server-side request forgery or deserialisation, then deploy webshells. Read the full ACSC alert.

Which CMS platforms are named in the ACSC alert?

The alert lists the exploited software and CVEs. Most are WordPress plugins, including Ninja Forms, Gravity Forms, WPvivid Backup and Breeze Cache, along with Craft CMS, Joomla JCE, MaxSite CMS and MetInfo CMS. The ACSC says these are public, known vulnerabilities with patches available, so any CMS left unpatched carries the same kind of risk.

How do you check if your website has a webshell?

The ACSC recommends inspecting your CMS for webshells, examining the web directory for abnormal changes to internet-facing files, checking plugin directories for unexpected new files, and reviewing web access logs for GET or POST requests to webshell paths. Treat any server with an identified webshell as compromised and isolate it.

What should you do if your website has been compromised?

Isolate the server, audit authentication and network logs, and look back for the initial exploitation. Remove or quarantine webshells and any persistence, patch the vulnerable software to prevent reinfection, and restore from a recent known-good backup. The ACSC takes reports at cyber.gov.au/report and on 1300 CYBER1 (1300 292 371).

Does a SaaS or evergreen CMS reduce this risk?

It can. The ACSC suggests applying security patches automatically where the risk of a faulty patch is low, and, for internet-facing websites, considering cloud services where the provider is responsible for rapidly fixing vulnerabilities. Platforms that update continuously avoid end-of-life gaps, but no platform removes the need to manage plugins and access.

Sources

  1. ASD's ACSC, Large-scale exploitation campaign targeting website content management systems (CMS), critical alert, published 9 July 2026.

Related insights

Authors
Founder & Chief Strategist
Dapth Marketing
Brand & Growth Team
Get in touch

We transform

Discover More insights.

One thing we won't apologise for? Our passion for the digital world.