FortiBleed Is Not a Zero-Day. That's the Point.

On June 16, security researcher Bob Diachenko found a server that was never meant to be seen. Inside it: the operational backend of a hacking group that had been quietly compromising Fortinet firewalls at industrial scale. Within 24 hours, Hudson Rock, SOCRadar, and Kevin Beaumont had all verified the data. The campaign, now called FortiBleed, is still active as of this writing.

The numbers: 73,932 unique firewall URLs across 194 countries. 21,632 unique domains affected. Approximately half of all internet-facing Fortinet devices. Many of the compromised devices were running recent firmware. This is not a story about unpatched systems.

It is a story about everything else that has to be right for a patch to matter.

No zero-day. No CVE. No novel exploit.

FortiBleed does not have a CVE. There is no new vulnerability to patch. The attackers used a simpler, older playbook: scan the internet for Fortinet devices with exposed management interfaces, then test them against a curated list of credentials drawn from previous Fortinet breaches and infostealer malware logs.

When a login succeeded, the device became a listening post. The attackers monitored VPN traffic to capture authentication hashes in transit, then cracked them offline using a 45-GPU cluster managed through Hashtopolis. Once inside a device, they pivoted into internal networks, Active Directory environments, SQL servers, and anything else reachable from the compromised gateway.

SOCRadar documented the self-feeding loop. Every compromised device was used to harvest more credentials, which were fed back into the scanner to compromise more devices. The operation processed 1.16 billion credential attempts against 320,000 FortiGate targets and an additional 2.1 billion attempts against 163,000 Microsoft SQL Server instances.

The PBKDF2 gap

The most interesting detail in this campaign is something Fortinet tried to fix in early 2025. In FortiOS versions 7.2.11, 7.4.8, and 7.6.1, Fortinet changed the way admin passwords are hashed, moving from SHA-256 with salt to PBKDF2, a significantly stronger key-derivation function. This was the right move.

Beaumont's analysis flagged a critical gap: the migration to PBKDF2 only applies when an administrator logs in after the firmware update. A device that was patched but whose admin accounts never re-authenticated stayed on the older SHA-256 format. Worse, even after conversion, Fortinet's firmware retains the old SHA-256 hash in a hidden old-password field for downgrade compatibility — and that old hash is visible in configuration backups.

This is how FortiBleed connects to the config export question. The leaked dataset contains email addresses and other data that are only accessible from a FortiGate configuration file, not from the SSL VPN login interface. The attackers almost certainly exported configs from compromised devices. With the config file and the device serial number, decrypting the file is straightforward. Once decrypted, the SHA-256 hashes are crackable at commodity GPU speeds. PBKDF2 would have made that exponentially harder.

The fix was shipped. It just never got completed on thousands of devices. That gap is the root cause of this breach.

Who was hit

The victim list reads like the Fortune 500: Foxconn, Samsung, Comcast, Siemens, Lenovo, FedEx, PwC, Accenture, Oracle, and Mercedes-Benz all appear in the data. The attackers categorized victims by company type, revenue, and country — a hallmark of eCrime syndicates packaging initial access for sale on dark web marketplaces.

The countries with the most affected devices are India, the United States, Taiwan, and Mexico. Every sector is represented: IT services, construction materials, telecommunications, and government agencies.

The most severe confirmed compromise involved a Turkish NATO defense contractor. Diachenko verified that the attackers exfiltrated classified defense documents from that organization. The attackers did not just collect credentials. They followed them to the data.

Still active

SOCRadar confirmed that the attacker's infrastructure was still running and adding new victims at the time of their report — and Hudson Rock noted that the dataset had not yet appeared for sale on criminal forums. The researchers published proactively to give affected organizations a head start before wider distribution.

This is not a historical breach. It is an ongoing campaign that organizations can still respond to.

What to do right now

Check if your domain is in the dataset. Hudson Rock operates a free lookup portal at hudsonrock.com. If you appear, assume your Fortinet credentials are in criminal hands.

Rotate every Fortinet admin and VPN password immediately. Complexity does not matter — passwords that were already in past infostealer dumps were cracked regardless of length.

Enable MFA on every Fortinet VPN and admin interface. A second factor renders a stolen password useless. This is the same fix that stopped the Meta AI Instagram takeover.

Verify your PBKDF2 migration status. Log into your FortiGate and check whether admin passwords are stored in PBKDF2 format (prefixed with PB2 in the config). If they show SH2, force re-authentication of all admin accounts against the latest firmware. To fully remove old SHA-256 hashes, enable login-lockout-upon-weaker-encryption in the system password-policy settings.

Remove the management interface from the internet. The FortiGate management interface should never be reachable from the public internet. Use a VPN to access it, or restrict it to trusted internal IPs via local-in policies.

Audit device logs for anomalous admin sessions. Look for logins from unexpected geographies, admin sessions at unusual hours, or configuration export events you did not initiate.

FortiBleed is not a zero-day. It is a thousand small failures that compounded into a massive one. Patched but not logged in. Rotated but not everywhere. Exposed but nobody checked.

The attackers did not need a new vulnerability. They just needed the existing defenses to stay incomplete. When the vendor shipped a fix and thousands of devices never completed the upgrade, that was not a software bug. It was the system working exactly as configured.