FortiBleed Is Not A Campaign. It Is An Audit Result. 86,644 Firewalls Failed Eight Years Of Fortinet's Own CVE Backlog.
- Patrick Duggan
- 1 minute ago
- 5 min read
The number being quoted is 86,644. The framing being applied is campaign. Both are correct and together they understate the problem by an order of magnitude. FortiBleed is not a campaign in the sense of a targeted actor running a sophisticated operation against specific victims. It is an audit result. Someone ran a credential collection pass against the global population of internet-exposed Fortinet devices and published what they found. What they found is that roughly half of every FortiGate firewall and FortiProxy VPN gateway reachable from the public internet was carrying working admin credentials extractable without current authentication. The 86,644 number is not the scale of the attack. It is the scale of the failure, measured in devices, across 194 countries, by one research pass.
The credential breakdown is the part that should end careers. Generic admin accounts are 35 percent of the compromised set. Built-in Fortinet system accounts are 28.3 percent. Organization-specific accounts are the remaining 36.7 percent. Put those first two numbers together and you get 63 percent of the breach coming from accounts that should never have been left with default or unrotated credentials on an internet-facing perimeter device. That is not a vulnerability. That is a provisioning failure, industrialized, harvested on schedule.
The CVE lineage in our Known Exploited Vulnerabilities index tells the eight-year story the headlines are skipping.
CVE-2018-13379 landed in CISA KEV on November 3, 2021. It is a path traversal in the FortiOS SSL VPN web portal that lets an unauthenticated attacker download FortiOS system files — including, in configurations of that era, files containing credential material — via a crafted HTTP request. The vulnerability is from 2018. It was catalogued by CISA as actively exploited in 2021. Three years of unpatched production firewalls before it even made the list.
CVE-2018-13382 followed into KEV on January 10, 2022. Improper Authorization in FortiOS and FortiProxy under the SSL VPN web portal — an unauthenticated attacker can modify passwords. Same vintage, one year later on the KEV clock.
CVE-2020-12812 joined KEV on November 3, 2021 alongside 13379. SSL VPN improper authentication — change the case in your username and bypass the second factor entirely. An MFA bypass that required a username case flip. In a VPN gateway. In production.
CVE-2022-40684 hit KEV on October 11, 2022. Authentication bypass across FortiOS, FortiProxy, and FortiSwitchManager via crafted HTTP requests to the administrative interface. Unauthenticated administrative access. The patch window between disclosure and KEV addition was measured in weeks; the patch window between KEV addition and full fleet remediation, for most organizations, was measured in months or not at all.
CVE-2024-55591 landed in KEV on January 14, 2025. Authentication bypass via the Node.js websocket module leading to super-admin privileges. Unauthenticated.
CVE-2025-24472 hit KEV on March 18, 2025. Authentication bypass via crafted CSF proxy requests leading to super-admin privileges. Also unauthenticated.
Six CVEs across eight years, every one of them authentication-related, every one of them unauthenticated, every one of them on an internet-facing perimeter device. The FortiBleed credential database is the downstream consequence of that eight-year window. Whoever collected those 86,644 sets of working credentials did not need a zero-day. They needed a list of internet-reachable Fortinet devices and the patience to work through the backlog.
The patch trap is the detail that makes this worse. Fortinet's 2025 firmware updates transitioned password hashing from SHA-256 to PBKDF2. The transition is correct. The implementation is a trap. Applying the firmware update does not re-hash existing passwords. Re-hashing only activates when an administrator logs in after the upgrade. Which means an organization that applied the security update in good faith, showed the patch in its compliance dashboard as complete, and never logged in again with the affected account, is still carrying a SHA-256 credential hash from 2019 on a device running the latest firmware. The patch indicator is green. The credential is still crackable in minutes on commodity hardware. This is not an edge case. Thousands of organizations are in this state right now, and they have no visibility into it because the vulnerability scanner said patched.
The credential composition confirms the time depth of the collection. Infostealer malware is listed as one of the three primary sources alongside the legacy hash exploitation and the unpatched CVE chain. Infostealers have been harvesting Fortinet admin credentials from endpoint memory and browser stores for years. The FortiBleed database is not a fresh exfiltration. It is an aggregation of credential material that has been circulating in criminal markets, combined with fresh hash-crack output from the SHA-256 population, combined with direct exploitation of the CVEs still alive in unpatched fleets. The result is a single database of 86,644 working logins that validates on contact.
194 countries is the other number that reframes the attribution. The Russian-speaking crew designation is probably accurate as primary operator. It is not a useful frame for defenders, because the database has almost certainly already been sold, shared, or leaked into broader criminal markets. The question is not who collected it. The question is who has it now and what they intend to do with it. A working admin credential for a perimeter firewall is not a credential. It is a set of keys to everything behind the firewall, including internal networks, VPN tunnels, authentication infrastructure, and whatever the firewall is logging about the organization's internal traffic. The 86,644 number is not 86,644 compromised firewalls. It is 86,644 organizations whose network perimeter is now someone else's asset.
The three actions are the same three they have been for six years of Fortinet KEV additions, which is its own kind of indictment. First, rotate every administrative credential on every internet-facing Fortinet device, regardless of patch status, because the patch does not retroactively invalidate credentials harvested before or during the window. Second, log in as each affected administrator account after the firmware upgrade to force PBKDF2 re-hashing, and confirm the re-hash completed in the device logs. Third, audit which of the six CVEs above have been patched and which are still live, treating each unpatched entry as a working attacker credential rather than a theoretical vulnerability, because the evidence is that it is.
The five percent we will not claim is that this is the only database. The ninety-five percent we will claim is that any organization operating an internet-facing Fortinet device with credentials older than the most recent rotation is already in a database somewhere, whether or not it is the one Volodymyr Diachenko found on June 19.
Patch the firmware. Log in to force the re-hash. Rotate the credentials. Do all three. The order matters because patching without logging in leaves the old hash, and rotating without patching leaves the authentication bypass. The eight-year backlog does not forgive partial remediation.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.