A leaked dataset dubbed FortiBleed exposes verified administrator and SSL VPN credentials for 73,932 internet-facing FortiGate firewalls across 194 countries — by multiple estimates, roughly half of every FortiGate reachable from the internet. This is not a fresh CVE; it is a credential-management weakness in FortiOS combined with offline cracking at scale. If you run FortiGate at your perimeter, treat your credentials as compromised until you have proven otherwise.

What happened

Security researcher Volodymyr “Bob” Diachenko spotted an exposed server last weekend belonging to a Russian-speaking cybercrime crew. The server held the group’s own tooling and artifacts — including a dataset of validated FortiGate credentials and full configuration exports. Kevin Beaumont, who reviewed a sample, confirmed “the logins and passwords are real” and noted the data was pulled from device config exports “as it includes things which are only visible from the device itself.” Many of the sampled devices are running fairly recent firmware, so a current patch level is no guarantee of safety here.

Hudson Rock, which stood up a lookup tool for the leak, counts 73,932 unique firewall URLs. Affected organizations include Samsung, Siemens, Foxconn, Oracle, Accenture, DHL, Infosys, numerous government agencies and critical-infrastructure operators — and Fortinet itself. Diachenko reported that at least four organizations across Japan, Taiwan/Vietnam, Iraq, and Turkey were fully compromised, including a Turkish NATO defense contractor whose classified documents were exfiltrated.

The root cause: legacy SHA-256 hashes

Until early 2025, FortiOS stored administrator passwords as salted SHA-256 hashes — fast to brute-force on modern GPUs. Fortinet later moved to PBKDF2 with a randomized salt, which is far more crack-resistant. The catch: when a device is upgraded from an older release, the old SHA-256 hashes persist until an administrator manually logs in to trigger re-hashing. Plenty of upgraded-but-not-re-authenticated devices still carry the weak hashes, sitting one offline crack away from a working login.

The crew automated the rest. According to Diachenko, they harvested SSL VPN authentication hashes and configuration exports at internet scale, cracked them on a 45-GPU cluster orchestrated with Hashtopolis, and used the recovered passwords to log into management interfaces and pivot into internal Active Directory. In most compromised cases, the FortiGate management interface was exposed directly to the internet. Fortinet’s read is that the dataset blends data collected during prior intrusions with fresh brute-forcing rather than a single new exploit.

Why it’s bad

A FortiGate sits at the network boundary. Working admin credentials let an attacker rewrite firewall rules, intercept or reroute VPN traffic, create backdoor accounts, disable logging, and stage ransomware or data exfiltration — silently, with no alert for defenders who are not actively threat hunting. Bitsight reports the credential pool is already being weaponized by both opportunistic criminals and more capable actors, citing post-exploitation tunneling tools (Chisel and Neo-reGeorg) previously seen in Volt Typhoon operations against Fortinet edge devices.

This is the same playbook that produced CVE-2018-13379 (≈50,000 VPN credential sets leaked in 2020), XORtigate (CVE-2023-27997), and the 15,000+ FortiGate configs dumped in 2025. Perimeter appliances stay at the top of the target list precisely because they straddle the internet and the internal network.

What to do now

Bitsight flags affected builds as FortiOS prior to 7.2.11, 7.4.8, and 7.6.1. Treat the following as urgent:

  • Assume compromise and rotate everything — admin accounts, local users, and SSL VPN credentials — regardless of whether a breach is confirmed.
  • Patch to FortiOS 7.2.11 / 7.4.8 / 7.6.1 or later, then log in after the upgrade to force migration off SHA-256 onto PBKDF2. Patching alone does not re-hash existing passwords.
  • Force strong hashing: on 7.6.x set login-lockout-upon-weaker-encryption; on 7.2.x/7.4.x use login-lockout-upon-downgrade.
  • Get management interfaces off the internet. Restrict admin access to trusted internal IPs, a VPN-only path, or out-of-band management. Keep SSL VPN portals public only where there is a clear business need.
  • Enforce MFA on every administrative and remote-access account.
  • Hunt for unexpected admin logins, newly created accounts, altered firewall rules, disabled logging, off-hours VPN sessions, logins from unusual geographies, and Chisel/Neo-reGeorg activity. Check your domains and IPs against Hudson Rock’s lookup tool.

If you find evidence of access, treat it as a full intrusion rather than a one-off login: rebuild from known-good configuration, rotate again, and run a proper investigation.

References