ACSC advisory on Fortinet credential exposure: what to fix first on firewalls and VPN gateways

An alert from the Australian Cyber Security Centre (ACSC), published on 18 June 2026, reports a widespread malicious campaign built on exposed credentials and credential-based attacks against Fortinet firewalls and VPN gateways. According to the advisory, which is aimed at Australians and Australian organisations that use Fortinet devices, the exposed credentials could let a malicious actor gain remote access to the devices and their connected networks and make changes to settings, including security controls.

What the advisory does and does not say

As an analysis published on dev.to points out, this is not a story about a newly disclosed software vulnerability being exploited. The ACSC describes credential-based attacks against internet-facing edge devices: the alert names no CVE, publishes no affected-version list, and gives no figure for affected devices or organisations. Those omissions matter for triage, because the scope of the event cannot be bounded from the advisory alone.

The alert's mitigation advice is a list: rotate all admin and VPN credentials immediately; ensure devices are patched against older-firmware vulnerabilities; keep firewall admin and management interfaces off the internet unless necessary; enforce MFA on all external interfaces; store credentials with PBKDF2 hashing, logging back in to admin accounts after the update so the encryption change takes effect; and examine authentication and access logs for abnormal logins or changes. An update to the alert notes that Fortinet has released a blog post with additional guidance and directs affected organisations to review and monitor it.

Why the fix order matters

The dev.to analysis argues that the list reads as a checklist but works better as a sequence, because the four main workstreams — credential rotation, management-plane restriction, MFA enforcement, and firmware currency — have different effort profiles, operational risks and dependencies. Run in the wrong order, they can waste effort or create new exposure.

Credential rotation goes first. It is the only control on the list that directly addresses the reported attack path, it takes effect fastest, and it usually needs no change window; the ACSC also says to do it immediately. The caveat is that rotation alone only resets the clock. A new credential on a device with an internet-reachable management interface and no MFA is exposed to the same collection path as the old one.

Management-plane restriction comes next because it removes the transport for credential attacks rather than merely changing the credential. The advisory's wording — interfaces should not be internet accessible 'unless necessary' — acknowledges that some organisations genuinely need remote management; for them the answer is to constrain access with source restrictions, jump hosts, or a VPN that is itself protected by MFA. This work is slower, since it touches network architecture and change control, but it is more durable than rotation alone.

MFA on all external interfaces raises the cost of a stolen credential, but it is high-friction: it depends on identity infrastructure, can break service accounts and automation, and requires enrolment and support. Sequencing it after the immediate exposure has been reduced lowers the chance of a rollback under pressure.

Firmware currency is general hardening rather than a response to a named flaw, and it carries the most operational risk: maintenance windows, potential VPN interruption and regressions. The dev.to piece places it on a planned cycle rather than in the same window as credential rotation, unless the estate is small and the change well understood. PBKDF2 hashing, with its log-back-in verification step, belongs inside the credential workstream, while log review is a detective control that should start early and continue, since it is how an organisation learns whether the preventive controls are holding.

The resulting order is: rotate, reduce exposure, raise authentication cost, then patch on a planned cycle, with log review running throughout. It is a sequence about dependency and risk rather than elapsed time; a small estate may compress it, while a large one may run management-plane restriction in parallel with rotation across different device groups.

Scoping the estate

Because the advisory provides no version list or victim count, organisations have to determine exposure from their own asset data. A ZoomEye query for FortiGate, cited in the dev.to analysis, returned 983,996 internet-observable assets observed on 23 September 2026. That figure counts observable devices — not compromised, vulnerable or victimised ones — and ZoomEye does not detect compromise. Its value is as a population-level denominator against which an organisation can compare its own externally visible footprint.

Why it matters

The alert is a reminder that not every urgent advisory maps to a CVE. When the vector is exposed credentials rather than a software flaw, version scanning cannot tell an organisation whether it is affected, and the response shifts to identity hygiene and exposure reduction. The sequencing argument is the practical core: rotating credentials without closing the management plane or adding MFA merely restarts the exposure clock, and skipping log review means never learning whether the controls held. With close to a million FortiGate devices visible on the internet, the discipline of rotate, restrict, harden, patch on a plan — and keep watching the logs — is what separates a contained incident from a recurring one.