FortiBleed: 86,000 Compromised FortiGates, No CVE, and a Number That Keeps Changing Meaning

On 6 October 2026 the FBI and the US Secret Service issued a joint advisory, JCSA-20261006-01, about an ongoing campaign against internet-facing FortiGate firewalls. The press called it a breach of tens of thousands of devices. It is worth being precise about what it actually is, because the single most important fact about FortiBleed is the one most of the coverage skips: there is no vulnerability and no CVE.

Nobody exploited a bug. The operators scanned for exposed FortiGate SSL-VPN and admin interfaces, replayed credentials from old Fortinet leak dumps and infostealer logs, cracked password hashes offline on rented GPUs, created their own administrator accounts, locked the real administrators out, and sold the working access on to ransomware affiliates. Every step uses the device exactly as designed. The only things that made it possible were exposure, legacy password hashing and missing multi-factor authentication.

//Not a Vulnerability

FortiBleed did not start in October. A researcher, Volodymyr Diachenko, found an exposed threat-actor server in mid-June 2026, and the first public reporting and a CISA hardening alert followed within days. The October FBI and Secret Service advisory is titled "Operations Continue" for a reason: this has been running for months, and the lockouts that prompted the joint advisory are a late symptom, not the beginning.

The mechanism is credential abuse end to end. Validated logins came from two places: credentials leaked in earlier Fortinet incidents, and credentials lifted from infostealer-infected machines whose owners had saved a FortiGate admin password in a browser. Where the operators captured hashes rather than plaintext, they cracked them offline with Hashcat, orchestrated by Hashtopolis across rented GPU infrastructure. That worked because older FortiOS stored administrator credentials with fast SHA-256 hashing, which is cheap to brute-force at scale. Fortinet now recommends PBKDF2 for admin credential storage on 7.2.11 and later, and removing the legacy hashes.

There is nothing to patch. A firmware update does not close this, because nothing is broken in the firmware. The fix is to stop exposing the admin and VPN interfaces, enforce phishing-resistant MFA so a valid password is not enough, and move credential storage off the legacy hash. This is the uncomfortable category of incident where "are we patched?" is the wrong question.

//The Numbers Do Not Agree

The headline figure everywhere is 86,644. What it counts depends on who you read. SOCRadar has used it to mean compromised devices; SecurityWeek rendered it as confirmed working credentials; Bitdefender described records from roughly that many unique devices. These are not the same thing, and the advisory ties the number to SOCRadar's own verification rather than to a government count.

Qualys made the point most bluntly: the various totals in circulation - figures around 30,800, 73,900, 74,000, 75,000 and 86,644 - are different objects measured by different methods at different times, and must not be added together or treated as interchangeable. Roughly 194 countries appear in the geographic spread. The honest way to cite the scale is "SOCRadar's figure of about 86,644, variously described as devices, credentials or records," and to leave it there.

This matters beyond pedantry. A defender deciding whether they are affected needs to know whether a number counts exposed devices or cracked credentials, because those imply completely different response urgencies. A count that has quietly shifted meaning three times in the retelling is not a number you can plan against.

//What Actually Catches It

Because there is no exploit signature to hunt, detection falls on the attacker's behaviour on the box. The strongest signal in the entire advisory is also the most boring: unexpected administrator accounts.

The operators reused a consistent set of admin account names across victims, and the advisory published them. If any of these appear in your FortiGate configuration and you did not create them, assume compromise:

adminin, forticloud-tech, gttadmin, fgtsecure, adminsslvpn, support_fortinet, forti_support2, forticloud-sync, system_config, IT_Manager, fgtsec, and several more in Table 2 of the advisory.

Account names are a far better indicator here than the network IOCs. The advisory lists C2 and brute-force IP addresses, but it also warns, in the same breath, that much of that infrastructure is cloud-hosted and already being reassigned. An IP you block today may belong to someone innocent next week. An administrator account named forti_support2 that you never created does not expire.

The two mitigations that end the campaign

Phishing-resistant MFA on every admin and remote-access path. Credential stuffing, spraying and offline cracking all produce the same thing: a valid username and password. MFA makes that insufficient, and the entire left-hand side of the chain collapses.

Get the admin interface off the internet. Trusted-host restrictions, then a local-in policy, then removing internet-facing administration entirely. An exposed login page is not proof of compromise, as Censys is careful to note, but it is the precondition for all of this. Remove the precondition and the scanning stage finds nothing.

//The Honeypot View

The first two stages of FortiBleed - mass scanning and credential stuffing from leaked and stolen lists - are not exotic. They are the constant background radiation of the internet, and they are exactly what this site's SSH honeypot records every single day. The 31-day honeypot corpus is a month of this same behaviour aimed at a different protocol: commodity wordlists, source addresses rotating across dozens of countries and ASNs to defeat blocklists, and a long tail of credential reuse.

That is the quiet lesson of FortiBleed. The techniques are not advanced. What made it a national-advisory event was not sophistication on the attacker's side but a large population of edge devices left exposed, hashed weakly, and protected by a password alone. The attackers did the ordinary thing at scale, against targets that had not done the ordinary defensive thing.

//Sourcing and Uncertainty

The attack chain, the rogue admin account names, the C2 and brute-force indicators, the lockout behaviour and the mitigations come from the FBI and US Secret Service joint advisory JCSA-20261006-01. The June origin, the exposed-server discovery and the figure-conflation warning come from Censys, Bitdefender and Qualys. The downstream ransomware names and the still-active status come from SOCRadar.

What is not established. The "45-GPU cluster" and the counts of roughly 1.16 billion credential attempts against 320,777 targets come from the researcher who found the exposed server and are flagged by Bitdefender as not independently confirmed. The advisory names no threat actor; descriptions of a "Russian-speaking group" and an access broker called "SantaAd" are unconfirmed. Three FortiCloud single-sign-on CVEs have been floated as a possible earlier source of some captured credentials, but that is vendor speculation about seeding, not the FortiBleed mechanism, and it is explicitly not confirmed.

One thing to keep straight. FortiBleed is not the PivotC2 campaign covered separately on this site. That one was a real CVE, CVE-2025-25249, with a post-exploitation implant, and the figures of 30,000 targeted and 178 infected belong to it. FortiBleed has no CVE and no implant in that sense - it is credential abuse and rogue accounts. Treating the two as one story, which some coverage does, gets both wrong.

The interpretation is mine: that the absence of a CVE is the central fact rather than a footnote, that the account-name list is a more durable indicator than the IP set, and that the honeypot's daily credential-stuffing traffic is the same phenomenon at a smaller scale.