The ASD says you now have hours to patch. What that means for public websites.

On 21 October I spent the night on php2shell, where a leaked PHP flaw had a working exploit circulating before the patch existed. Five days later the Australian Signals Directorate published its Annual Cyber Threat Report 2025–26, and it described that night in one sentence: “In the past, defenders had months to patch, now they have days, sometimes only hours.” The ASD has a year of national incident data behind that sentence, where we only have our own platform to go on.

The report calls AI “the defining force in the cyber threat landscape over the past year”, and its first response is to ask organisations to strengthen and accelerate their patching. Alongside that sits a plainer instruction about how much of your organisation should be reachable from the internet at all, and most public web estates in Australia could act on it this quarter. Over the same year the ISM itself changed a lot, mostly without much attention, and several of those changes land on the people who build and run public websites.

What the ASD saw this year

Government accounted for almost half of the incidents reported to the ASD. The ASD puts part of that down to government’s stronger reporting obligations, which is fair, but it still means government systems take close to half of the national response effort.

The most common way in was phishing, in 39% of the incidents the ASD analysed, followed by compromised accounts at 21% and valid accounts at 15%. The report says stolen usernames, passwords, tokens and sessions “are now among the most common pathways into Australian networks”, and that matters for public websites too, because the admin login of a CMS is one of the most valuable credentials an organisation exposes. The report also records a successful exploitation of a vulnerability first identified in 2008, so some systems stay online unpatched for well over a decade.

The window has gone from months to hours

The ASD says it has previously observed that most vulnerability exploitation happens within two weeks, with some CVEs exploited within 48 hours of a patch or mitigation advice being released, and it expects AI-driven tools to compress that window further over the next 12 months. Our night on 21 October fits inside those numbers like this.

The report is careful about what AI has and has not changed. In the ASD’s words, “AI capabilities have not introduced new cyber threats, but they have amplified existing ones”. The attacks are the ones we have defended against for years, such as unpatched software and stolen credentials, and what has changed is that they arrive faster and at greater scale, with far less expertise needed to carry them out. The report is just as clear that AI cuts both ways, and describes it as having “the potential to be a force multiplier for defenders” in threat detection, vulnerability management and incident response.

Expose less

The resilience chapter asks organisations to accelerate their patching. Next to that, it says:

The ASD gives the reason in the same sentence: “AI-enabled exploitation is shrinking the window between vulnerability discovery and compromise.” If the time to patch is now shorter than the time it takes most organisations to rebuild and redeploy, then every system you take off the internet is one less system that has to be patched inside that window. I have been arguing for this since Back To The Static in 2021, when the case was mostly about speed and cost, and the ASD’s advice supports the same conclusion on security grounds.

The report’s own examples show how ordinary the exposed stack usually is. In May a single collective notification about cPanel vulnerabilities went to 340 organisations and led to more than 60 confirmed incidents, and in the same month the ASD published an advisory on ClickFix malware being spread through compromised WordPress sites to target Australian infrastructure.

For a typical government or university web estate, a large share of what is exposed is a CMS serving content that only changes when an editor publishes. Here is what the internet can reach in each model, comparing a CMS that serves the public directly with the same CMS publishing to a static front end.

During php2shell, some of our customers were still on Drupal 7 and PHP 7.4 behind a static front end, and they had nothing to do that night, because no PHP ran anywhere in their public request path. I want to be clear that this is a mitigation until the upgrade is done. The ASD is direct that the most effective way to deal with legacy technology is to replace it before it goes out of support, and a static front end buys time to do that safely.

The ISM already asks for a CDN and a hidden origin

Long before this report, the ISM’s guidance on service continuity for online services set out the same pattern.

ISM-1438: “Where a high availability requirement exists for website hosting, CDNs that cache websites are used.”

ISM-1439: “If using CDNs, disclosing the IP addresses of web servers under an organisation’s control (referred to as origin servers) is avoided and access to the origin servers is restricted to the CDNs and authorised management networks.”

In our experience, many estates miss ISM-1439. Putting a CDN in front of a site is easy, but if the origin still answers anyone who finds its IP address, an attacker can go around the CDN and its WAF entirely. A static front end has no public origin, so for a dynamic application, restrict the origin so it accepts only traffic that has come through the edge, either by allowing only the CDN’s source ranges or by requiring a secret header or mutual TLS that only the edge can present.

You can test this, and two other common gaps, in five minutes with nothing more than a terminal.

SITE=www.example.gov.au

# 1. What does the site tell the world about its stack?
#    Version headers make an attacker's target selection easier.
curl -sI "https://$SITE" | grep -iE "^(server|x-powered-by|x-generator|x-drupal-cache):"

# 2. Can the origin be reached around the CDN? (ISM-1439)
#    Use the origin IP from your hosting records. If this returns your site,
#    anyone who finds that IP can bypass the CDN and its WAF.
curl -sk --max-time 10 -o /dev/null -w "%{http_code}\n" \
  --resolve "$SITE:443:<origin-ip>" "https://$SITE/"

# 3. Does the site offer hybrid post-quantum key exchange? (OpenSSL 3.5 or later)
echo | openssl s_client -connect "$SITE:443" -servername "$SITE" \
  -tls1_3 -groups X25519MLKEM768 2>&1 | grep "Negotiated TLS1.3 group"

If the first check shows a CMS name and version, you are telling every scanner exactly which advisory to look up. If the second returns a 200, your origin is reachable directly, which is the specific gap ISM-1439 is written to close. If the third returns nothing, your TLS termination does not support post-quantum key exchange yet, which is the subject of the last section below.

What changed in the ISM this year

The Essentials launch got the headlines in October, but the ISM itself moved a long way between December 2025 and September 2026. We compared every release in that period using the ASD’s machine-readable catalogue, and these are the changes I think matter most to teams who build and run public websites and the applications behind them.

The password change in December reverses the complexity rules that many login forms still enforce, and I expect plenty of them to keep demanding a symbol and a number for a while yet. The agentic AI controls in September are the first time the ISM has addressed AI agents this directly, and they are written for exactly the kind of chat assistants that are now appearing on public sites.

The dependency controls cover the build side of the supply chain, which the report illustrates with the Shai-Hulud worm: it compromised hundreds of software packages by stealing developer credentials and republishing poisoned versions. A public site has a second supply chain that runs in its visitors’ browsers, made up of the analytics tags, chat widgets, font loaders and tag managers it loads from other people’s domains. Most sites write their Content Security Policy as a list of allowed domains, so if a trusted vendor is compromised and starts serving different code from the same domain, the policy lets it straight through. Hashes and Subresource Integrity can pin a script’s exact content, but they break every time the vendor ships an update, so in practice third-party tags rarely use them.

Post-quantum key exchange

The ASD wants organisations to stop using traditional asymmetric cryptography by the end of 2030, and ISM-1917 requires new cryptographic equipment, applications and libraries to support ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by then. For most public websites a sensible first step is the TLS key exchange, which check 3 above tests.

We ran that check against our own edge and a sample of customer sites on both QuantCDN and QuantGov, and every one negotiated X25519MLKEM768 by default. That is the hybrid of classical X25519 and post-quantum ML-KEM-768 that current major browsers already offer, and it protects traffic recorded today from being decrypted later by a quantum computer. ISM-1917 goes further, because it names ML-KEM-1024 as the target parameter set, and certificates are a separate problem again, because public certificate authorities do not yet issue post-quantum certificates, so signatures across the whole web are still classical.

What I would do this quarter

If you run public websites for government, this is the order I would work in.

1. List every system and service your organisation exposes to the internet, including the old ones nobody has touched in a year, and run the three checks above against each public site.
2. Check how fast you can actually patch an internet-facing system today, from advisory to production, and compare it with the 48-hour window.
3. For each public website, decide whether its public side needs a runtime at all. Most content sites do not, and can be published as static files without changing how editors work.
4. For the sites that must stay dynamic, put them behind a WAF you can update quickly, restrict the origin so that only the edge can reach it, and set up a static failover so you can take the runtime out of the public path during an incident.
5. Work through the ISM changes in the table above, starting with password rules and session revocation, because those are the ones your users will notice.
6. Collect your WAF and audit logs centrally. In one of the ASD’s ransomware case studies, comprehensive event logs showed that no data had been stolen, which gave the organisation confidence that a disruptive incident was limited in scope.
7. Report suspicious activity to the ASD at cyber.gov.au or on 1300 CYBER1 (1300 292 371). In the report’s SonicWall case study, reports from several organisations let the ASD identify the vulnerability being exploited and warn around 40 more organisations that were potentially vulnerable.

About QuantCDN

Quant is an Australian edge platform: a CDN and WAF combined with static web hosting, with Quant Cloud for the applications that have to stay dynamic. We make Drupal and WordPress static, support the popular static site generators, and host government, education and enterprise sites across Australia. If you are working through the new ASD Essentials series, our ASD Essentials for cloud mapping shows which actions a provider can carry and which stay with you. If you want help working out what your organisation exposes, contact us.