What Exposure Counts Do Not Prove: A Methodology Note on the Fortinet Credential Advisory

On 18 June 2026, the Australian Signals Directorate's Australian Cyber Security Centre (ACSC) published an alert titled "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways". Written for all Australians and Australian organisations that use Fortinet devices, it was updated on 22 June 2026. As with most advisories concerning internet-facing security appliances, the event was quickly discussed alongside internet-wide scan counts of Fortinet devices. That juxtaposition is where the methodology problems begin, because a device that is observable on the internet and a device that has been compromised are two different things, and it is worth being precise about which one any given number measures.

This note separates what the advisory reported from what a scan can show, and uses two ZoomEye observations made on 23 September 2026 to illustrate the difference.

What the advisory actually reports

The ACSC states that it 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 stated consequence is that "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 framing matters. The advisory describes credential-based attacks against internet-facing edge devices. It does not describe the exploitation of a newly disclosed software vulnerability. That distinction shapes how any supporting data should be interpreted, because credential exposure is an operational and configuration problem, and it does not necessarily map onto version boundaries or a single flaw.

It is equally important to note what the advisory does not contain. It does not publish an affected version list. It does not name a CVE. It does not state how many devices or organisations were affected. Any figure attached to this event that claims to be a count of victims or compromised systems therefore does not come from the advisory itself.

The mitigation advice is concrete: rotate all admin and VPN credentials immediately; ensure devices are patched against older-firmware vulnerabilities; restrict management interface exposure so that firewall admin and management interfaces are not internet accessible unless necessary; enforce multi-factor authentication on all external interfaces; store credentials with PBKDF2 hashing (the alert notes that logging back in to admin accounts after updating causes the stored encryption to change to PBKDF2); and examine authentication and access logs for abnormal logins or changes. An update section states that Fortinet released a blog post and additional guidance, which affected organisations should review and monitor: https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices

Why a fingerprint is not a vulnerability confirmation

Internet-wide search engines such as ZoomEye index assets observable from the internet and attach fingerprints to them, such as a product name or an operating system label. A fingerprint match tells you what a device appears to be. It does not tell you whether the device is patched, whether its credentials are exposed, whether its management interface should be reachable at all, or whether anyone has ever logged into it maliciously.

For this event the gap between "fingerprinted" and "affected" is wider than usual, precisely because the reported attack path is credential-based. A FortiGate device running current firmware with MFA enforced and a management interface that is not internet accessible could match the same fingerprint as an unpatched device with a re-used admin password. The fingerprint is identical; the risk posture is not.

What the ZoomEye observations measure

Two ZoomEye queries were observed on 2026-09-23:

• The query app="FortiGate" returned an exact_count of 983996, with status ok, observed 2026-09-23T17:14-17:15Z.
• The query app="FortiGate" && os="FortiOS" returned an exact_count of 39538, with status ok, observed 2026-09-23T17:14-17:15Z.

The second query is the one worth foregrounding for this event, because it is the narrower of the two: it requires both a FortiGate application fingerprint and a FortiOS operating system fingerprint to match. The large difference between the two counts is itself instructive. The broader product tag evidently matches a much larger population of assets than the joint query, which indicates that fingerprint labels in scan data are constructed from different signals of varying confidence. Neither figure should be treated as ground truth about anything except what it is: a count of internet-observable assets matching the query at the time of observation.

That is exactly what both counts are. They are not a count of compromised devices. They are not a count of vulnerable devices. They are not a count of victims. ZoomEye's reported count is the number of internet-observable assets matching the query. Reading either figure as "the number of breached Fortinet firewalls" would be a category error.

A concrete, verifiable use: exposure review and triage order

What, then, can these observations honestly be used for? One concrete and verifiable use is exposure review and triage ordering for an organisation that operates Fortinet devices.

A network owner can run app="FortiGate" && os="FortiOS", scoped to their own address space, to produce an inventory of their internet-observable FortiGate and FortiOS assets as seen from an external scanning perspective. This inventory can be cross-checked against the organisation's own asset records to identify devices that are internet-facing without being documented as such. Each confirmed asset then becomes a triage target for the ACSC's mitigations, in a defensible order: verify that the management interface is not internet accessible unless necessary, confirm MFA is enforced on all external interfaces, rotate admin and VPN credentials, confirm credentials are stored with PBKDF2 hashing, verify patch status against older-firmware vulnerabilities, and review authentication and access logs for abnormal logins or changes.

The same query can be re-run periodically as continuous monitoring, with each observation recorded with its dork, count and timestamp so that drift in the count is attributable to changes in exposure rather than to changes in methodology. The essential discipline is measurement hygiene: record what was queried, when it was observed, and never present the resulting figure as anything other than an exposure count.

Reading the advisory and the counts together

The honest reading of this event keeps three claims separate. First, the ACSC has reported a widespread campaign that largely uses exposed credentials and credential-based attacks against Fortinet Firewalls and VPN gateways, which could enable remote access to devices and connected networks and changes to settings including security controls. Second, scanning on 2026-09-23 showed 983996 internet-observable assets matching app="FortiGate" and 39538 matching app="FortiGate" && os="FortiOS". Third, there is no verified link between those two datasets: no CVE, no affected version list, and no victim count appears in the advisory, and a scan count does not measure compromise.

The overlap between the scanned population and the affected population is unknown. What the scan legitimately provides is a prioritised, externally verifiable starting list for the mitigations the ACSC recommends. What it does not provide, and cannot provide, is proof that any counted device has been compromised.

References

[1] Australian Signals Directorate's Australian Cyber Security Centre, "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways", published 2026-06-18T07:18:43Z, updated 22/06/2026, available via the ACSC website: cyber.gov.au

[2] ZoomEye query results, app="FortiGate" (exact_count 983996) and app="FortiGate" && os="FortiOS" (exact_count 39538), both status ok, observed 2026-09-23T17:14-17:15Z: zoomeye.org

[3] Fortinet, "Analysis of reported credential compromise of FortiGate devices", referenced in the ACSC alert's update section: fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices