TLS Certificates as Corroborating Evidence on Internet-Facing FortiGate Gateways

On 18 June 2026 the Australian Cyber Security Centre (ACSC) published an advisory titled "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways" [1]. The advisory 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" [1]. It describes credential-based attacks against internet-facing edge devices, not the exploitation of a newly disclosed software vulnerability. The ACSC does not publish an affected version list, does not name a CVE, and does not state how many devices or organisations were affected [1].

That absence of a version list or CVE is not an oversight; it follows from the nature of the event. When the primary vector is a valid credential rather than a software flaw, the affected population is defined by exposure and credential hygiene, not by a firmware range. This is precisely the situation in which a second, independent signal about the device population becomes useful. TLS certificate properties are one such signal. They do not prove compromise, and they do not identify vulnerable devices, but they can corroborate that a given set of internet-facing gateways is large, homogeneous, and worth prioritising for the advisory's recommended checks.

What the advisory actually says

The ACSC advisory is aimed at "all Australians and Australian organisations that use Fortinet devices" and at a technical audience [1]. Its stated consequence is that "[l]everaging 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" [1]. The recommended mitigations are operational rather than patch-specific: 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 MFA on all external interfaces; store credentials with PBKDF2 hashing, logging back in to admin accounts after updating so the encryption changes to PBKDF2; and examine authentication and access logs for abnormal logins or changes [1].

The advisory's update section notes that Fortinet released a blog post and additional guidance, and directs affected organisations to review and monitor that post [1]. It does not publish an affected version list, does not name a CVE, and does not state how many devices or organisations were affected [1]. Any article that supplies those numbers is supplying them from somewhere other than the advisory.

Why a second signal is useful

A single fingerprint can be wrong or incomplete. A banner string can be spoofed, a management page can be proxied, and a hostname can be reused. When the question is "how large is the population of internet-facing FortiGate gateways that I should be thinking about?", one indicator is a starting point, not a conclusion. A second indicator that is collected independently — for example, a TLS certificate property observed during the same scan — can either corroborate the first or show that it is over- or under-counting.

The inference must be stated carefully. A certificate property is an observation about how a device presents itself on the network. It is not a vulnerability claim, not a compromise indicator, and not a statement about firmware. The correct framing is: "this many internet-observable assets match this query on this date", followed by an explicit note that the count measures internet-observable assets rather than compromised assets.

The ZoomEye observations

ZoomEye observations collected on 2026-09-23 provide two counts relevant to this discussion. The query app="FortiGate" returned an exact count of 983996 (status ok, observed 2026-09-23T17:14-17:15Z) [2]. The narrower query app="FortiGate" && ssl.cert.pubkey.rsa.bits=2048 returned an exact count of 254801 (status ok, observed 2026-09-23T17:14-17:15Z) [2].

Both figures are counts of internet-observable assets matching the respective query. They are not counts of compromised devices, not counts of vulnerable devices, and not counts of victims [2]. The second query does not identify a vulnerability; it identifies assets whose observed TLS certificate uses a 2048-bit RSA public key. That property is common and is not by itself a weakness. Its value here is corroborative: it shows that a substantial subset of the observable FortiGate population presents a consistent certificate profile, which is the kind of structural observation that helps an analyst reason about a population rather than about a single host.

A concrete use: scoping an exposure review

The advisory's mitigation list includes restricting management interface exposure and enforcing MFA on all external interfaces [1]. Before either can be done at scale, an organisation needs to know which of its own assets are internet-facing and how they present. The ZoomEye queries above can be used as a measurement-hygiene step in that process.

A defensible workflow is as follows. First, run the broad query app="FortiGate" to establish the size of the observable population you are reasoning about, and record the observation date alongside the count [2]. Second, run the narrower query app="FortiGate" && ssl.cert.pubkey.rsa.bits=2048 to see how much of that population shares the observed certificate property [2]. Third, compare the two counts against your own asset inventory. If your inventory contains internet-facing FortiGate gateways that do not appear in either result, that is a discrepancy worth investigating — it may indicate a device that is not reachable from the vantage point used, or an inventory record that is stale. If your inventory is much smaller than the observable population, the gap is a reminder that the observable population is global and not a list of your assets.

The same queries can support triage order. An organisation that must rotate credentials and review authentication logs across many devices can use the certificate-property query to group assets that share a presentation profile, then prioritise the group that is both internet-facing and externally reachable. This is asset identification and exposure review, not compromise detection. ZoomEye does not detect compromise, and neither query should be described as doing so.

Limits and cautions

Three limits should be stated plainly. First, the ACSC advisory does not name a CVE, does not publish an affected version list, and does not state how many devices or organisations were affected [1]. Any figure presented as a victim count would be unsupported. Second, the ZoomEye counts are observations of internet-observable assets on a specific date, and they will change as devices are patched, retired, or newly exposed [2]. They are a snapshot, not a census. Third, a certificate property is not a security control. The presence of a 2048-bit RSA public key in an observed certificate says nothing about whether MFA is enforced, whether credentials have been rotated, or whether the device is patched. Those questions are answered by the advisory's recommended checks, not by a scan result.

The advisory's own framing is the right one to keep in view: the campaign is reported, it largely uses exposed credentials and credential-based attacks, and the consequence could be remote access and changes to security controls [1]. The response it recommends is credential rotation, patching against older-firmware vulnerabilities, restriction of management interface exposure, MFA on external interfaces, PBKDF2 credential storage, and log review [1]. TLS certificate observations do not replace any of that. They add a second, independent signal about the population that needs it.

References

[1] ACSC, "Reported widespread credential exposure affecting Fortinet Firewalls and VPN Gateways", published 2026-06-18T07:18:43Z, updated 22/06/2026. https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/reported-widespread-credential-exposure-affecting-fortinet-firewalls-and-vpn-gateways

[2] ZoomEye query results, observed 2026-09-23T17:14-17:15Z: app="FortiGate" exact_count=983996; app="FortiGate" && ssl.cert.pubkey.rsa.bits=2048 exact_count=254801. https://www.zoomeye.org/