Shared and Managed Fortinet Estates: Whose Gateway Is It When Credentials Leak?

When a national cyber security agency advises organisations to "rotate all admin and VPN credentials immediately," that instruction quietly assumes something important: that the reader controls the credentials being rotated. The Australian Signals Directorate's Australian Cyber Security Centre (ACSC) alert of 18 June 2026, titled "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways," rests on exactly that assumption. For organisations whose Fortinet edge devices are hosted, co-managed, or operated entirely by third parties, each of the alert's recommended actions becomes a question of ownership before it becomes a question of technique.

This article reviews what the advisory says, what the evidence does and does not establish, and how internet-exposure measurements — including recent ZoomEye observations of the Fortinet footprint — can support the asset-identification and triage work that shared and managed estates need before any credential rotation can begin.

What the advisory says

The ACSC alert, published on 18 June 2026, states that the ACSC is aware of public reporting of a widespread malicious campaign against Fortinet Firewalls and VPN gateways, "largely utilising exposed credentials and credential-based attacks, leading to potential compromise and further credential exposure." The alert frames the consequence in conditional terms: leveraging these credentials "could enable malicious actor's remote access to the devices and connected networks, as well as allow changes to various settings, including security controls."

The mitigation advice is conventional for a credential-exposure event, and it is worth listing in full because each item maps to a specific operator role:

• Rotate all admin and VPN credentials immediately.
• Ensure devices are patched against older-firmware vulnerabilities.
• Restrict management interface exposure; firewall admin and management interfaces should not be internet accessible unless necessary.
• Enforce MFA on all external interfaces.
• Store credentials with PBKDF2 hashing, which for existing accounts requires logging back in to admin accounts after updating so the stored encryption changes to PBKDF2.
• Examine authentication and access logs for abnormal logins or changes.

The alert also notes that Fortinet has released a blog post and additional guidance, and that affected organisations should review and monitor it: https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices

Importantly, the alert describes credential-based attacks against internet-facing edge devices. It is not framed as the exploitation of a newly disclosed software vulnerability, and it does not publish a CVE identifier, an affected version list, or a count of affected devices or organisations.

The ownership gap in a managed estate

Consider each mitigation through the lens of a device the reader does not directly administer. Credential rotation requires knowledge of which accounts exist, where they are stored, and which service accounts may break when passwords change. Patching against older-firmware vulnerabilities requires a change window negotiated with the managed service provider — and often with the provider's other customers on shared hardware. Management-interface exposure is frequently a deliberate design choice made when the contract was signed; the provider may rely on internet-reachable administration. MFA enforcement on external interfaces may be constrained by the provider's authentication stack. Even the PBKDF2 step, which depends on an admin logging back in after an update, requires an actor who holds admin credentials. And log review presumes the customer can access authentication and access logs at all.

None of this makes the advisory wrong. It makes it incomplete for a specific class of reader. Where the gateway sits in a hosting arrangement, a co-management split, or a fully outsourced security operations contract, the technical steps are executable only after an ownership question is answered explicitly: who holds the administrator accounts, who holds the VPN user directory, who can see the logs, and who is contractually obliged to act — and on what timeline?

The alert's audience is "all Australians and Australian organisations that use Fortinet devices" — deliberately broad. But a reader who has outsourced the gateway cannot discharge that responsibility with a ticket that says "please rotate credentials." They need an inventory of which devices they are responsible for, which party controls each one, and which of those devices are actually reachable from the internet.

Evidence and its limits

Two kinds of evidence are available for this event, and both have limits that matter for shared estates.

First, the advisory itself. It is an awareness alert based on public reporting, not a vulnerability bulletin. It names no CVE, lists no affected firmware versions, and states no victim counts. An organisation cannot determine from the alert alone whether its firmware is in scope, or whether any specific device has been targeted. That ambiguity is uncomfortable, but it is also why the advisory's mitigations are framed as blanket hygiene: rotate credentials, patch older firmware, restrict exposure, enforce MFA, check logs. In a managed estate, the absence of an affected-version list makes the ownership question even more acute, because the provider — not the customer — usually holds the firmware inventory.

Second, external exposure measurements. ZoomEye observations, taken on 2026-09-23 between approximately 17:14 and 17:15 UTC, give a sense of how large the internet-observable Fortinet footprint is. The query product="Fortinet" returned an exact count of 4,526,062 internet-observable assets. The narrower query app="FortiGate" returned 983,996, and app="Fortinet FortiGate" returned 39,006. These are counts of assets matching each query as observed from the internet. They are not counts of compromised devices, not counts of vulnerable devices, and not counts of victims. ZoomEye does not detect compromise, and nothing in these observations should be read as attributing any state to any specific device beyond its internet observability at the time of the scan.

The three figures are also not three estimates of one population. They are the results of three different queries against different fingerprinting dimensions, and the spread between 4.5 million, 984 thousand, and 39 thousand illustrates how much the measured footprint depends on which attribute a query targets. Any use of these numbers must carry that caveat.

A concrete, verifiable use: asset identification and triage order

For a shared or managed estate, the most direct use of these observations is asset identification as the first step of triage. The advisory's first mitigation — immediate credential rotation — cannot be scoped without knowing which gateways exist and which are internet-facing.

A customer of a managed security provider can run the same dorks and compare results against the provider's asset register. If the provider's documentation claims, for example, three internet-facing FortiGate gateways for the customer's tenancy, but the customer's own exposure review — whether via ZoomEye or an equivalent service — shows administrative interfaces or VPN endpoints reachable from the internet that do not appear in that register, the ownership question has surfaced in a verifiable way: someone is administering a device nobody has accounted for.

The observations also support triage ordering across a portfolio. An organisation managing dozens of sites through different providers can treat internet-observable management interfaces as the first tier for the advisory's "restrict management interface exposure" mitigation, since those are the assets for which credential exposure converts most directly into remote access. Devices that are observable but present only VPN endpoints sort into a second tier for credential rotation and MFA enforcement. This is prioritisation based on observability, not on any claim about which devices are attacked or compromised — the advisory provides no data supporting such a claim.

Finally, the same queries are repeatable. Re-running product="Fortinet" and the narrower FortiGate queries after remediation gives a before-and-after view of whether management exposure has actually been reduced — precisely the kind of verification a customer cannot get from a provider's assurance report alone.

Conclusion

The ACSC alert is technically sound but organisationally one-sided: it addresses a reader who owns the device, the credentials, the logs, and the change process. In shared and managed Fortinet estates, the alert's mitigations amount to a checklist of contract clauses waiting to be checked. Credential rotation, PBKDF2 re-authentication, MFA, exposure restriction, and log review all require an explicit answer to one question first — whose gateway is it? External exposure measurement cannot answer that question, but it can force it to be asked, and it can verify the answer afterwards.

References

1. Australian Signals Directorate's Australian Cyber Security Centre, "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways," published 2026-06-18, updated 22/06/2026.
2. ZoomEye query results for product="Fortinet" (4,526,062), app="FortiGate" (983,996), and app="Fortinet FortiGate" (39,006), observed 2026-09-23T17:14-17:15Z.
3. Fortinet PSIRT blog, "Analysis of reported credential compromise of FortiGate devices," as referenced in the ACSC alert.