FortiBleed Isn't a Campaign. It's an Audit Result — and 86,644 FortiGate Firewalls Just Failed It.

On June 19, 2026, CISA warned Fortinet customers that the working credentials for 86,644 internet-facing FortiGate appliances had been collected into one verified database, spanning 194 countries with telecom, government, and education hit hardest. My first writeup framed this as a Russian-speaking credential-spraying campaign. After reading Patrick Duggan’s breakdown, I don’t think that framing survives contact with the facts — so this is the rewrite.

Patrick’s reframe is simple and, once you see it, hard to unsee: FortiBleed isn’t a campaign, it’s an audit result. The 86,644 figure isn’t a victim count from one operation. It’s the measured scale of provisioning failure — what a single scan of internet-reachable Fortinet devices returns when you work through everything the vendor and its customers left exposed since 2018. The database surfaced when researcher Volodymyr “Bob” Diachenko found an open server holding it alongside the operator’s tooling. But the contents predate that discovery by years.

Eight years, six CVEs, zero zero-days

The core of Patrick’s argument is that nobody had to be clever. They needed a list of internet-facing Fortinet endpoints and the patience to run a backlog. Six authentication-related FortiGate CVEs — every one already on CISA’s Known Exploited Vulnerabilities list — did the work:

• CVE-2018-13379 SSL VPN path traversal; unauthenticated download of credential files KEV Nov 2021
• CVE-2018-13382 Improper authorization; change a password with no authentication KEV Jan 2022
• CVE-2020-12812 MFA bypass via username case manipulation KEV Nov 2021
• CVE-2022-40684 Unauthenticated admin access via crafted HTTP requests KEV Oct 2022
• CVE-2024-55591 Node.js websocket auth bypass to super-admin KEV Jan 2025
• CVE-2025-24472 CSF proxy auth bypass to super-admin KEV Mar 2025

Patrick makes a point I glossed over entirely: CVE-2018-13379 sat for roughly three years before CISA flagged it as actively exploited. That is the kind of gap that turns a patch advisory into a credential pipeline. Each unremediated flaw didn’t just risk a single breach — it deposited working logins into a pool that someone eventually scooped up wholesale.

The credential breakdown is the tell

SOCRadar’s analysis of the leaked set is the most damning detail, and it lines up exactly with the audit framing. Generic admin accounts make up 35 percent and built-in Fortinet system accounts another 28.3 percent — so 63.3 percent of the breached credentials are default or factory accounts that were never renamed or rotated. That isn’t a target list an attacker had to build. It’s one the defenders handed over by leaving the factory configuration in place on an internet-facing box.

The remaining 36.7 percent are organization-specific accounts — the more alarming slice, because those weren’t defaults. They were credentials the organizations created themselves and never changed, most likely sourced from prior breaches and infostealer logs. Credential reuse is doing as much damage here as any single CVE.

The hash trap: “patched” on paper, crackable in practice

Fortinet introduced PBKDF2 hashing for administrator credentials in FortiOS 7.2.11, 7.4.8, and 7.6.1, replacing legacy salted SHA-256. The catch — and Patrick is sharper on this than my first draft — is the upgrade behavior: existing admin passwords stay stored as SHA-256 until that admin actually logs in after the upgrade. An organization can show “patched” in every scanner while still carrying a 2019-vintage SHA-256 hash that cracks in minutes on commodity hardware. The compliance dashboard says done; the device says otherwise.

Three sources, one database

Put together, the 86,644 entries aren’t the output of one clever operation. They’re an aggregation of three streams that have been running for years: crackable legacy SHA-256 hashes pulled from configs, the unpatched CVE chain above, and infostealer malware quietly lifting admin credentials from endpoint memory and browsers. Even Fortinet’s own response points this way — the company told The Hacker News the data is “likely a resharing of data from previous incidents… not related to any current incident.” Read plainly, that’s the vendor confirming the audit-result framing: this is accumulated old exposure, not a new break-in. Operationally it changes nothing — the credentials are valid right now against live devices.

As Patrick puts it, 86,644 sets of working credentials means 86,644 organizations whose network perimeter is now someone else’s asset. A firewall login isn’t one box — it’s the VPN tunnel, the internal network, and the authentication plane behind it.

What to do this week — and the order matters

Patrick’s sequencing is the part to internalize, because doing these out of order leaves the door open:

1. Rotate every administrative credential on internet-facing Fortinet devices, regardless of patch status. Patching does not invalidate credentials that were already harvested.
2. Log in as each admin after the firmware upgrade to force PBKDF2 re-hashing, and confirm in the logs that no legacy SHA-256 hash remains.
3. Audit which of the six CVEs are still unpatched, and treat each unpatched one as a working attacker credential rather than a theoretical vulnerability.

Then the standard hardening: terminate active SSL VPN and admin sessions, rename or disable default and built-in accounts, enforce phishing-resistant MFA on every external gateway, pull management interfaces off the public internet, and hunt your firewall, VPN, authentication, and domain-controller logs for the configuration changes that signal a foothold.

Full credit for the reframe and the sharper technical read goes to Patrick Duggan’s analysis — go read the original, and connect with him on LinkedIn.