FortiBleed exposes credentials for 73,932 FortiGate firewalls

What pulled us in this week was not a new CVE. There was no advisory page to read, no PSIRT note, no patch to deploy. Instead, an open server on the internet quietly waited for a researcher to walk in, and when Volodymyr Diachenko opened the door he found one of the largest verified collections of working Fortinet VPN credentials ever published, covering 73,932 FortiGate devices, 21,632 domains, and 194 countries, with names like Samsung, Mercedes-Benz, Foxconn, Chevron, Comcast, AT&T, and Toyota sitting in plain text inside the same JSON files as a NATO defence contractor and a long list of government agencies (Help Net Security, CISA advisory).

The actor was Russian-speaking, the dataset assembly was patient and industrial, and the bug at the bottom of all of it was something most defenders never put on a vulnerability queue at all, namely the choice of one hash function on the gateway your remote workforce signs into every morning.

The weak link is the hash function under the password

SHA-256 was designed to be fast. Feed it a file and it computes a fingerprint quickly enough to verify a Linux ISO at gigabytes per second, which is exactly what you want when you are checking integrity. The same speed is the worst possible property for password storage, because an algorithm that verifies a file in milliseconds also lets an attacker test billions of password guesses per second on a stack of consumer GPUs.

PBKDF2 was built for the opposite job. It runs the underlying hash many thousands of times in a chain, so verifying one valid login stays invisible to a human while testing a trillion guesses takes years instead of an afternoon, and a random per user salt kills any precomputed rainbow table on the way in. The arithmetic settles the question: the same 45 GPU rig that grinds through SHA-256 at billions of attempts per second crawls through a properly tuned PBKDF2 at roughly a thousand attempts per second, the gap between a twelve character password that falls in a day and one that holds for centuries. A fast hash protecting a high value identity is the entire bug FortiBleed rests on. It has no CVE, it is not in NVD, and a scanner will not find it, because the pattern simply sat on the inside of every FortiGate built before Fortinet flipped the default.

How the actor turned that hash into 73,932 working logins

When a remote user opens the FortiGate portal and submits a password, the gateway computes a hash from the submitted secret and the device's stored salt, then compares it to its stored credential record. An attacker who can reach the management or VPN interface and is willing to throw millions of guesses at it gets two useful outcomes. Response timing and error structure reveal which usernames exist, and at scale the captured authentication exchanges feed offline cracking against any stored hashes the attacker has previously pulled from leaked configs.

The FortiBleed actor automated the entire pipeline. Dataset assembly began with a sweep of 59.3 million internet-facing hosts for exposed FortiGate management interfaces, narrowed to 320,777 confirmed FortiGate targets, then ran roughly 1.16 billion credential-based login attempts to probe them and intercept SSL VPN authentication handshakes (Help Net Security, Bank Info Security). Hashes that came back went into a 45 GPU Hashtopolis cluster, the open-source distributor that lets a handful of operators pool GPUs into one cracking job, and because the underlying admin hashing scheme on most reachable devices was still legacy SHA-256 with salt, the cluster crunched through the dataset at rates that effectively turned long passwords into short ones. Recovered plaintexts were then walked into the Active Directory environments behind the VPN, which is where the operation actually monetized.

Two operational details turn old hash on edge gear into a quietly serious problem for defenders. Fortinet did fix the underlying weakness: starting in FortiOS 7.2.11, 7.4.8, and 7.6.1, administrator passwords are stored under PBKDF2 with a randomized per user salt instead of SHA-256, which kills the cracking economics laid out above (Fortinet docs, Fortinet community thread). The catch is that the migration is silent and partial. Existing admin password hashes stay in the legacy SHA-256 format on disk until each individual administrator next logs in to that specific device, so any organization that upgraded six months ago and lost track of which appliances had a quiet admin who never logged back in still has legacy hashes sitting on those boxes, which is precisely the population FortiBleed harvested.

Why a CVSS-first queue never surfaces it

Most vulnerability management programs would not surface FortiBleed for a working analyst at all, because the platform's source of truth is a CVE feed. The exposure here is a configuration outcome, a fleet of FortiGates whose stored admin hashes are still SHA-256 because nobody re-logged in after the upgrade, sitting on a management or VPN interface that is reachable from any IP an actor with a botnet can rent. A CVSS-first queue sees nothing, while the actor is already moving laterally inside the Active Directory behind those boxes. Raw CVSS does not capture configuration debt of this shape, which is why a noisy week of unrelated nine plus advisories will keep the queue busy while the real exposure on your perimeter keeps quietly aging.

What to actually do this week

1. Treat every internet-reachable FortiGate admin and SSL VPN credential as compromised today, rotate them, and terminate all active VPN sessions to invalidate any in-flight intruder, in line with CISA's June 18 advisory (CISA).
2. Upgrade affected appliances to a FortiOS release that supports PBKDF2 storage, namely 7.2.11, 7.4.8, or 7.6.1 and later, and after the upgrade force every administrator to actively log in to each device so the stored hash is rewritten from legacy SHA-256 to PBKDF2 (Fortinet docs).
3. Enable MFA on all VPN and administrative authentication paths, because the cracking economics described above assume single-factor login.
4. Pull authentication logs back to the start of the year and look for successful logins from ASNs or geographies that do not match your remote workforce, plus admin actions outside any approved change window.
5. Walk the Active Directory environment behind the VPN for accounts created or elevated since the start of 2024, and rotate any service account credential the FortiGate ever proxied.

How CVEasy AI sees this

A weekly queue ranked by raw CVSS has nothing to flag here, because the bug that costs you the Active Directory behind your perimeter this week does not have a CVE. That is exactly the shape TRIS, the prioritization engine inside CVEasy AI, the number one local-first CTEM platform, exists to float to the top of a noisy week, by reasoning about real exposure rather than advisory metadata, on your own hardware.

References

• CISA, Urges Hardening Fortinet Devices After Reports of Credential Exposure (June 18, 2026)
• Help Net Security, 74,000 Fortinet Firewall Credentials Exposed in FortiBleed Data Leak
• Security Boulevard, FortiBleed Leak Exposes VPN Credentials for Nearly 74,000 Fortinet Devices
• Bank Info Security, Crime Gang Sells Access to 74,000 Fortinet Firewall Devices
• Fortinet, Enhanced Administrator Password Security in FortiOS 7.6.1
• Fortinet community, Enforcing PBKDF2 as hash function for administrator accounts in FortiOS v7.2.11 and later