Could Your Website Be at Risk?
Yes. If your organisation operates a website built on WordPress, Drupal, Joomla, Craft CMS or another content management system, you should assume your website is being scanned for known vulnerabilities. The ASD’s Australian Cyber Security Centre (ACSC) has confirmed an active exploitation campaign targeting vulnerable CMS platforms and plugins, with Australian businesses already affected. Immediate patching, monitoring and security validation are recommended. (Cyber Australia)
For many organisations, the company website is often viewed as a marketing asset. It’s where customers learn about products and services, submit enquiries or access online portals. From a security perspective, however, it’s also one of the most exposed systems within the business.
Unlike internal applications protected by VPNs or corporate firewalls, public websites are designed to be accessible from anywhere in the world. That makes them a constant target for automated scanning, vulnerability discovery and exploitation attempts.
On 9 July 2026, the Australian Signals Directorate’s Australian Cyber Security Centre (ACSC) issued a Critical alert warning of a large-scale campaign targeting vulnerabilities across content management systems (CMS) and associated plugins. According to the advisory, attackers are actively scanning internet-facing websites and exploiting known vulnerabilities to deploy webshells, gain persistent access and compromise web servers. The campaign is global, but Australian organisations, particularly small and medium businesses, have already been impacted. (Cyber Australia)
This isn’t a warning about a single vulnerability.
It’s a warning about a campaign.
That distinction matters because attackers aren’t relying on one newly discovered exploit. They’re systematically identifying websites running known vulnerable software and attempting to compromise them at scale. If your CMS or one of its plugins hasn’t been updated, your website may already be part of those automated scans.
This Isn’t Just a WordPress Problem
When news breaks about website vulnerabilities, WordPress often receives most of the attention because of its popularity. While WordPress sites are certainly part of the current campaign, the ACSC’s alert is much broader.
The campaign targets vulnerabilities across multiple CMS platforms and associated plugins, including WordPress plugins, Craft CMS, Joomla components and several other content management systems. The common factor isn’t the platform itself. It’s the presence of known vulnerabilities that attackers can exploit before organisations apply security updates. (Cyber Australia)
That’s an important point because many organisations assume they’re protected simply because they don’t use WordPress.
Security doesn’t depend on the name of the platform.
It depends on how well it’s maintained.
Whether your website runs on WordPress, Drupal, Joomla, Craft CMS or a custom-built content management system, the same questions apply:
- Is the CMS fully patched?
- Are all plugins and extensions actively maintained?
- Have unused plugins been removed?
- Is the administrative interface appropriately secured?
- Are suspicious changes being monitored?
The attacker’s objective remains exactly the same regardless of which platform you’re using.
Find an exposed vulnerability.
Gain access.
Maintain persistence.
Move deeper into the environment if possible.
Why CMS Platforms Continue to Be Attractive Targets
Content management systems sit at the centre of many organisations’ digital presence. They manage public websites, customer portals, online forms, eCommerce platforms and business content.
Because they’re internet-facing, they’re also continuously accessible to attackers.
Modern attack campaigns don’t involve individuals manually searching for vulnerable websites one at a time. They rely on automation.
Threat actors continuously scan the internet looking for websites running vulnerable software versions or exposed plugins. Once a match is identified, exploitation attempts often begin within minutes.
The ACSC notes that attackers are using vulnerabilities that enable:
- Unauthenticated file uploads.
- Remote code execution.
- Server-side request forgery (SSRF).
- Deserialisation attacks.
These weaknesses allow attackers to deploy webshells, which provide persistent remote access to compromised web servers. Once a webshell is installed, the website effectively becomes a foothold inside the organisation’s environment. (Cyber Australia)
Depending on how the website is configured, attackers may then attempt to:
- Deface the website.
- Steal customer information.
- Capture credentials entered through online forms.
- Install additional malware.
- Use the compromised server as a staging point for broader attacks.
- Pivot into internal systems if the web server has unnecessary network access.
This is why a compromised website should never be viewed as “just a website issue.”
In many environments, it’s the first step towards a much larger security incident.
Who Should Be Paying Attention?
One misconception surrounding CMS vulnerabilities is that they primarily affect large enterprises.
The opposite is often true.
Small and medium-sized organisations frequently rely on third-party plugins, outsourced website development and shared hosting environments. These businesses may also have limited internal resources to monitor security advisories or rapidly apply updates, making them attractive targets for automated exploitation campaigns.
If your organisation operates any of the following, this alert should be treated as relevant:
- A corporate website built on WordPress, Drupal, Joomla or another CMS.
- A customer portal or member login.
- An eCommerce website.
- A marketing website with contact forms or downloadable content.
- A website managed by an external agency or hosting provider.
- A custom CMS that incorporates third-party plugins or components.
Even if website management has been outsourced, responsibility for cyber risk doesn’t disappear.
One of the first questions organisations should be asking this week is:
“Has our website provider reviewed the ACSC alert, confirmed whether we’re affected and applied any required security updates?”
If the answer isn’t immediately clear, now is the time to ask.
What Should Organisations Do Right Now?
When the ACSC issues a Critical alert, the expectation isn’t that organisations simply acknowledge the advisory. It’s that they assess their exposure immediately and take practical steps to reduce the risk of compromise.
The good news is that responding doesn’t always require a major technology project. In many cases, organisations already have the processes they need. The challenge is ensuring those processes are carried out quickly and thoroughly.
If your organisation operates a website or web application, these should be your immediate priorities.
1. Confirm What You’re Running
Before anything else, identify exactly which CMS platform, plugins, themes and extensions are running in your environment.
This sounds straightforward, but many organisations discover they have:
- Legacy plugins that are no longer supported.
- Development websites still accessible from the internet.
- Old staging environments.
- Components installed years ago that are no longer maintained.
You can’t secure software you don’t know exists. Maintaining an accurate inventory of your website components is the first step towards effective application security.
2. Apply Security Updates Immediately
The current campaign is targeting known vulnerabilities rather than undisclosed zero-day flaws. That means, in many cases, security updates are already available.
Prioritise:
- CMS core updates.
- Plugin and extension updates.
- Theme updates.
- Web server security patches.
- Underlying operating system updates where applicable.
If an update isn’t available, consider temporarily disabling the affected component until a fix is released.
The longer a vulnerable system remains internet-facing, the greater the opportunity for attackers to exploit it.
3. Remove What You No Longer Need
One of the simplest ways to reduce your attack surface is to remove unnecessary software.
During security assessments, it’s common to find plugins that haven’t been used for months or even years. They remain installed because nobody wants to risk breaking the website, but every inactive plugin still represents additional code that must be maintained and secured.
Ask yourself:
- Are all installed plugins still required?
- Are inactive plugins completely removed?
- Are unsupported themes still present?
- Are test environments publicly accessible?
Reducing complexity often improves security more than adding another security product.
Patching Is Only Part of the Response
Applying security updates is essential, but organisations shouldn’t assume the risk disappears the moment a patch is installed.
One important question remains:
Was the website compromised before the update was applied?
If attackers exploited the vulnerability before remediation, simply installing the latest version won’t remove webshells, malicious administrator accounts or other persistence mechanisms they may have established.
That’s why the ACSC also recommends reviewing systems for indicators of compromise and monitoring for suspicious activity following remediation.
Some practical checks include:
- Reviewing administrator accounts for unexpected changes.
- Looking for unfamiliar files or scripts within web directories.
- Monitoring web server logs for unusual requests.
- Checking for unexpected outbound network connections.
- Verifying file integrity where possible.
If suspicious activity is identified, the incident should be investigated rather than assuming the update resolved the issue.
Why Vulnerability Scanning Isn’t Enough
Many organisations regularly scan their websites for known vulnerabilities, and that’s an important part of any security programme.
However, vulnerability scanners answer only one question:
“Is a known vulnerability present?”
They don’t tell you:
- Whether the vulnerability is actually exploitable.
- How difficult exploitation would be.
- Whether multiple weaknesses can be chained together.
- What business impact successful exploitation could have.
That’s where application security testing becomes critical.
During an application penetration test, security consultants assess how an attacker would realistically interact with the website. Rather than simply identifying missing patches, they evaluate authentication controls, business logic, session management, API security and how vulnerabilities could be combined to compromise the application.
For example, a scanner might identify an outdated plugin.
A penetration test asks:
- Can that plugin actually be exploited?
- Does it provide administrative access?
- Can it expose customer information?
- Can it be combined with another weakness to achieve remote code execution?
Those answers help organisations prioritise remediation based on real business risk rather than simply counting vulnerabilities.
Website Security Doesn’t End After Deployment
One of the biggest misconceptions surrounding websites is that security is primarily a project completed before launch.
In reality, websites require continuous maintenance.
Content management systems evolve.
Plugins receive updates.
New vulnerabilities are disclosed every week.
Business requirements change.
Without ongoing security management, even a well-built website gradually becomes more exposed over time.
This is why many organisations are moving towards continuous application security rather than relying solely on annual penetration tests or reactive patching.
A mature website security programme typically includes:
- Regular application penetration testing.
- Ongoing vulnerability management.
- Secure code reviews for custom applications.
- Continuous monitoring for suspicious activity.
- Patch management processes.
- Independent security assessments following significant changes.
Together, these activities provide far greater confidence than relying on updates alone.
Security Should Extend Beyond the Website
The current CMS exploitation campaign is a reminder that websites are often the public face of an organisation’s technology environment.
If attackers gain a foothold through a vulnerable application, the impact may extend well beyond the website itself.
That’s why application security should be viewed as part of a broader cyber security strategy rather than an isolated responsibility for web developers.
Protecting internet-facing applications means understanding how they connect to identity services, cloud platforms, databases and internal systems. Every integration should be reviewed with the same level of scrutiny as the application itself.
The organisations that respond most effectively to campaigns like this aren’t necessarily those with the largest security teams.
They’re the ones that know what applications they’re running, understand their exposure, and regularly validate that security controls continue to work as intended.
Frequently Asked Questions
Who is most at risk from the current CMS exploitation campaign?
Any organisation running an internet-facing content management system should review its exposure immediately. This includes websites built on WordPress, Drupal, Joomla, Craft CMS and custom CMS platforms that rely on third-party plugins or extensions. The greatest risk lies with systems that are unpatched, poorly maintained or no longer actively supported.
If my website is fully patched, am I protected?
Applying security updates is one of the most important steps, but it shouldn’t be the only response. If attackers exploited a vulnerability before patches were applied, they may have already established persistence through webshells, malicious administrator accounts or modified files. Organisations should review logs, investigate indicators of compromise and consider an independent application security assessment.
How often should a website undergo security testing?
There isn’t a single schedule that suits every organisation. As a minimum, internet-facing applications should be independently tested annually. Additional testing is recommended after major application releases, significant infrastructure changes, cloud migrations or the introduction of new authentication mechanisms and third-party integrations.
What’s the difference between vulnerability scanning and application penetration testing?
A vulnerability scanner identifies known weaknesses such as outdated software or missing security patches. An application penetration test goes further by determining whether those weaknesses can actually be exploited, assessing authentication, business logic, APIs and chained attack paths that automated tools may not detect. Together, they provide a much clearer understanding of an application’s real-world security posture.
Conclusion
The ACSC’s latest advisory serves as an important reminder that website security is never static. Attackers aren’t waiting for organisations to catch up. They’re continuously scanning the internet for vulnerable CMS platforms, outdated plugins and exposed applications that can be compromised with minimal effort.
For Australian organisations, the priority should be understanding whether they’re exposed, applying security updates quickly and validating that those updates have addressed the actual risk. Just as importantly, businesses should consider whether a compromised website could provide attackers with a pathway into more critical systems or expose sensitive customer information.
Responding to the current campaign isn’t simply about patching software. It’s about building a sustainable application security programme that combines secure development, regular penetration testing, continuous monitoring and ongoing vulnerability management. Organisations that adopt this approach will be far better prepared for future threats, rather than reacting only when the next critical advisory is published.
How Intrix Can Help
At Intrix, we help Australian organisations secure the applications that are most exposed to attackers. Our consultants assess websites, customer portals, APIs and cloud-hosted applications to identify vulnerabilities before they become security incidents, providing practical remediation advice based on real business risk rather than automated scan results.
Our Application Security services combine independent testing with secure development practices to help organisations strengthen internet-facing applications throughout their lifecycle. For businesses looking for continuous assurance rather than point-in-time testing, our AppSec as a Service offering provides ongoing application security support, helping teams identify vulnerabilities earlier, validate remediation efforts and improve security as applications evolve.
Our application security capabilities include:
- Web Application Penetration Testing
- API Security Assessments
- Secure Code Reviews
- Application Security Architecture Reviews
- Cloud Application Security Assessments
- DevSecOps and Secure Development Advisory
- Continuous Application Security through AppSec as a Service
A public-facing website is often the first system attackers encounter, but it shouldn’t become the easiest way into your organisation. Whether you’re responding to the latest ACSC advisory or looking to strengthen your long-term application security programme, Intrix can help you identify exploitable weaknesses, validate security controls and reduce the risk of compromise before attackers have the opportunity to exploit them. Contact Intrix today.
