The ACSC Just Told You Your Website Is the Attack Surface

On 9 July 2026 the ACSC issued a critical alert that most Australian businesses will never read, because it is addressed to “website owners or website managers” and marked for a technical audience. In most organisations, nobody is quite sure who that is.

That ambiguity is the whole problem, and we will come back to it.

What the ACSC said

A large-scale exploitation campaign is targeting vulnerabilities in content management systems globally, including in Australia, with many small to medium sized Australian businesses impacted. Attackers are actively scanning websites looking for a way in, and where they find one they deploy a webshell: a small piece of code that gives them remote control of your web server.

Once that is in place, the ACSC lists what they do with it: deface or disrupt the site, capture credentials entered by your website users or other data stored on the server, upload further malware to target and scam your legitimate visitors, and use the server as a pathway into your broader network.

The exploited software is a roll-call of things sitting on ordinary Australian business websites right now: WordPress plugins including Simple File List, WavePlayer, BerqWP, WPBookit, Ninja Forms, ThemeREX Addons, Breeze Cache, ACF Extended, WPvivid Backup and Gravity Forms; plus Craft CMS, MaxSite CMS, MetInfo CMS and Joomla JCE. The flaws allow unauthenticated file upload, remote code execution, server-side request forgery or unsafe deserialisation.

The AI angle the ACSC quietly slipped in

Buried in the alert is a line worth pausing on. ASD notes that the heads of the Five Eyes cyber security agencies recently released a joint statement on how advances in AI are accelerating the speed and scale of cyber operations, reducing the time between vulnerability disclosure and exploitation.

Read that as an operational fact rather than a headline. The window between “a patch is released” and “your site is being scanned for that exact flaw” used to be measured in weeks. It is now considerably shorter, and shrinking. Patch cadences designed around a monthly maintenance window were built for a threat landscape that no longer exists.

The auditor’s point: your website is an asset you never registered

I have audited a lot of information security management systems, and I can tell you where the corporate website usually sits in them: nowhere.

The asset register lists laptops, servers, the CRM, the finance system, the file shares. The website is not there, because the website is “marketing”. It was built by an agency three years ago, it lives on hosting nobody in the business has logged into, its plugins were chosen by whoever was building it that week, and the person who knew the admin password has left. Ask an organisation who owns the corporate website and you will often get a pause, then a name, then a correction.

Now read the ACSC’s list of consequences again with that in mind. The unowned asset is internet-facing by definition. It captures credentials and form submissions, which, if you have a contact form, means it is collecting personal information. And it is a pathway into your corporate network. That is not a marketing problem. That is an information security problem that has been quietly filed under marketing.

Look at the exploited plugin list once more. Notice how many of them are form plugins: Ninja Forms, Gravity Forms, Simple File List, WPBookit. Forms are precisely where personal information enters your business. A webshell on the server that processes your enquiry form is not a defacement risk; it is an OAIC notification waiting to happen.

We checked our own site, and you should check yours

It would be a poor look to write this without doing it ourselves, so: this site runs WordPress, and it runs Ninja Forms, which appears on the ACSC’s list. We checked.

The relevant vulnerability, CVE-2026-0740, is in the Ninja Forms File Uploads extension, a separate paid add-on, rather than the core forms plugin. We do not run that extension, our plugins are current, and we are not exposed. That took about ten minutes to establish, and it is exactly the ten minutes we would ask you to spend.

It is also a warning about how these alerts get read. The ACSC’s table says “Ninja Forms”, which is precise enough for a technical audience and alarming enough to send a lot of business owners into a spin this week. Check the specific CVE and the specific component before you panic, and before you relax.

What the ACSC wants you to do right now

If you have any doubt, treat this as a live incident rather than a reading exercise. The ACSC’s immediate advice, in short:

1. Inspect your CMS for webshells. Look for abnormal changes to internet-facing files, and for unexpected files in the directories of any vulnerable plugin you run.
2. Examine your web access logs for GET or POST requests to webshell paths.
3. Treat any server with a webshell as compromised. Isolate it and audit authentication and network logs for malicious activity.
4. Look back in time. Trace the suspicious requests that led to the initial exploitation. The webshell is the symptom, not the beginning.
5. Hunt for persistence and lateral movement: new accounts, exfiltration attempts, further malware.
6. Patch, remove the malware, then restore from a known-good backup if there are signs of compromise. Patching alone does not evict an attacker who is already inside.

And to reduce the odds of it happening again, the ACSC’s hardening advice is refreshingly concrete: keep software and plugins rapidly patched; consider applying security patches automatically where a bad patch can be rolled back easily; disable any plugin with an actively exploited vulnerability until it is fixed; make web directories read-only so a webshell cannot be written in the first place; restrict which files and paths can be accessed; monitor for unexpected child processes spawning from the web server; and block unnecessary network traffic between the website and the rest of your corporate environment.

That last one deserves emphasis. If your website server can reach your corporate network, you have connected an unpatched, unowned, internet-facing box to the systems that run your business. Segmenting it costs almost nothing and removes the worst outcome on the ACSC’s list.

“Our web agency looks after that”

Possibly. But do you know that, or do you assume it? The ACSC anticipates this exact answer and says plainly: if a service provider maintains your website, point them to this alert.

In ISO 27001 terms this is straightforward supplier management. Does your web agency have a contractual obligation to patch? On what timeframe? Do they tell you when they have? Would they tell you if the site had been compromised? Most web development contracts I have read say a great deal about revisions and hosting fees, and nothing whatsoever about vulnerability management. That is not the agency being dishonest. Nobody asked them.

And to be clear about where the buck stops: if your site leaks customer data, it is your notification to make. The OAIC will not be interested in your web agency’s service agreement.

Where this lands in ISO 27001 and the Essential Eight

The Essential Eight has “patch applications” as one of its eight strategies, and I would wager most organisations that claim maturity against it are thinking about Windows, Office and their line-of-business software. Almost nobody counts the WordPress plugins on the marketing site. Yet that is where the campaign is landing, and that is where the data is.

ISO 27001 is less easily fooled, because it starts from a question the Essential Eight does not ask: what information assets do you have, and who owns each one? Answer that honestly and the website appears on the register, an owner is named, patching becomes somebody’s documented responsibility, the agency becomes a managed supplier, and “was the site compromised?” becomes a question your incident process can actually answer.

None of that is exotic. It is just the difference between having controls and having a website.

Frequently asked questions

We’re a small business with a simple brochure site. Are we really a target?

Yes, and not because anyone chose you. This is automated, indiscriminate scanning for known flaws, which is precisely why the ACSC says many small and mid-sized Australian businesses have been impacted. You are not being targeted; you are being found.

How do I know if I run one of the affected plugins?

In WordPress, look at your Plugins list and compare it to the ACSC’s table, then check the specific CVE, because in at least one case the vulnerability sits in a paid add-on rather than the plugin most people recognise by name. If a provider maintains the site, send them the alert and ask for a written answer.

If we patch now, are we safe?

Patching stops the next intrusion. It does nothing about one that already happened. A webshell installed last month survives the update. That is why the ACSC’s advice starts with inspect, not patch. If you find evidence of compromise, restore from a known-good backup.

Would this be a notifiable data breach?

It could be. If a webshell captured credentials or form submissions containing personal information, and serious harm is likely, the NDB scheme is engaged. The question you should be able to answer quickly is what data your website actually holds or transmits, and most organisations cannot.

Speak with an experienced ISO 27001 auditor

The technical remediation here belongs to whoever runs your website. The governance question is the one worth fixing permanently: why an internet-facing system holding customer data was never on your asset register, never assigned an owner, and never covered by your patching process.

Start with a gap analysis, or read more on cyber and information security advisory and how to use cyber.gov.au to protect, report and recover. Email hello@streamline.business or call us.

• Brisbane 07 3667 8280
• Sydney 02 8315 7780
• Melbourne 03 9034 3990

Source: ASD’s ACSC, “Large-scale exploitation campaign targeting website content management systems (CMS)”, critical alert, 9 July 2026, including the full table of affected software and CVEs, and the complete mitigation guidance. If you are impacted, report via cyber.gov.au/report.