FortiBleed: Inside the Campaign That Cracked 75,000 Fortinet Firewalls
| June 30, 2026
Key Takeaways
- FortiBleed exposes working admin and SSL VPN credentials for roughly 75,000 internet-facing Fortinet FortiGate firewalls across 194 countries.
- There is no CVE and no patch; FortiBleed stems from stolen configs, credential reuse, and offline hash-cracking.
- Root causes are FortiGate management interfaces exposed publicly and legacy SHA-256 hashing that left credentials crackable offline.
- PBKDF2 hashing only takes effect after each admin re-authenticates, leaving many devices still storing weak SHA-256 hashes.
- Affected organizations span every sector and size, with the IT services and telecommunications sectors hit hardest worldwide.
- Mitigate by removing management interfaces from the internet, forcing PBKDF2, enforcing MFA, and upgrading FortiOS.
In mid-June 2026, the security community began tracking one of the largest FortiGate credential exposures on record. Dubbed FortiBleed, the campaign has produced verified, working administrator and VPN credentials for tens of thousands of internet-facing FortiGate firewalls across nearly every country on earth.
What makes it especially serious is that the credentials are real, many of the affected devices are still online, and the attackers used the firewalls themselves as listening posts to burrow deeper into victim networks.
This post walks through what FortiBleed is, why it happened, who is affected, and the concrete steps to take if your organization is exposed.
What Is FortiBleed?
FortiBleed is an active, large-scale credential leak affecting roughly 75,000 internet-facing Fortinet FortiGate firewalls across 194 countries. The exposed data contains working login credentials for these devices, covering both firewall administrator accounts and SSL VPN logins [1].
It was first reported publicly on June 13, 2026, by security researcher Volodymyr "Bob" Diachenko, who flagged an exposed attacker directory containing potentially working FortiGate credentials.
Importantly, FortiBleed has no CVE and no patch to apply. It is not a single software vulnerability. It is a credential exposure built from stolen FortiGate configuration files, credential reuse, and offline hash-cracking, and the exact initial-access vector remains unconfirmed.
How does the FortiBleed attack work?
The operation follows a methodical five-stage attack chain by Russian-speaking initial access brokers [2]:
- Reconnaissance: Mass scanning with tools like Masscan and Shodan to find internet-facing FortiGate devices, then ranking targets by revenue and value.
- Initial access: Credential stuffing and SSH brute-force against FortiGate admin and SSL VPN accounts, using passwords sourced from prior breach dumps and infostealer logs.
- Sniffer deployment: Once inside, the actors deploy a custom Go-based sniffer, FortigateSniffer, that abuses the built-in FortiOS diagnose sniffer packet command to passively capture authentication traffic across 24 protocols.
- Exploitation: Captured hashes (NTLM, Kerberos, RADIUS) are cracked offline on a 45-GPU cluster managed with Hashtopolis, then reused to move laterally into Active Directory and other internal systems.
- Exfiltration: Sensitive data is pulled from network shares, and stolen session cookies are replayed to keep authenticated access.
What Was the Root Cause of FortiBleed?
The root cause of FortiBleed is two-fold: FortiGate management interfaces exposed to the public internet, and a legacy password-hashing weakness that left stored admin credentials crackable offline [3].
1. Exposed management interfaces and stolen config files
In most affected cases, the FortiGate Management Interface was reachable directly from the public internet. The leaked data appears to come from exported device configuration files, because it contains details only visible from the device itself.
Once attackers have a config file, they can extract the credential hashes and crack them offline. Exactly how the configs were exported is still unconfirmed. It may stem from one of Fortinet's known CVEs or a newer flaw.
2. Weak legacy hashing: the SHA-256 vs. PBKDF2 gap
The deeper technical cause is how FortiGate historically stored admin credentials. Fortinet introduced stronger PBKDF2 hashing (randomized salt, thousands of iterations) in FortiOS 7.2.11, 7.4.8, and 7.6.1, replacing the older, weaker SHA-256 with Salt.
The critical catch: after upgrading, an admin's password stays stored as a SHA-256 hash until that admin logs in again. PBKDF2 only takes effect once each administrator re-authenticates. As a result, many devices, even on recent firmware, kept storing credentials in the crack-friendly SHA-256 format.
A hidden old-password setting can also retain the previous SHA-256 hash for backward compatibility, visible in a super_admin config backup [4].
Which Companies Are Affected by FortiBleed?
FortiBleed affects organizations of every size and sector across 194 countries, from small businesses to Fortune-scale enterprises, with the IT services and telecommunications sectors hit hardest.
Named high-profile victims
Organizations identified in the leaked dataset include:
- Foxconn, Samsung, Comcast, Siemens, Lenovo, PwC, Accenture, Oracle
- Chevron, AT&T, Mercedes-Benz, Toyota, Sinopec, State Grid
- Numerous government agencies and critical infrastructure operators, including a small number of Fortune Global 500 enterprises
How do I check if I'm affected by FortiBleed?
To check FortiBleed exposure, go to this website, enter your organization's domain or public IP, and review the results.
A "not found" result is not a clean bill of health. With about 50% of internet-facing FortiGates in scope, assume you may be affected and act accordingly. Use these steps:
Check your exposure on Shodan
Search your public IP ranges (for example, org:"Your Company" product:FortiGate). If your management interface (port 443/10443) is visible, it was almost certainly in scope for automated scanning used by attackers.
Look for indicators of compromise (IoCs)
Check for unexpected admin logins, new or unknown accounts, configuration changes, and unusual log activity.
What Should I Do If My Organization Is on the FortiBleed List?
If your organization appears in the FortiBleed dataset, treat your network perimeter as already compromised and act immediately:
- Rotate all affected credentials now: Change every FortiGate admin and SSL VPN password.
- Rotate Active Directory credentials too: The sniffer harvested NTLM and Kerberos hashes for internal users, so any AD account could be at risk.
- Hunt for backdoors: Look for backdoor admin accounts or altered security settings. Rotating a password will not remove an attacker who created persistence. If you find suspicious admin logins, consider replacing or factory-resetting the device, preserving logs first.
- Review logs for prior access: Check for unfamiliar IPs, unexpected admin sessions, and config changes. Note that offline cracking may leave no log of the original theft.
- Hunt for downstream compromise: Investigate other devices reachable by, or sharing credentials with, the compromised firewall.
How to Mitigate Risk of FortiBleed?
To mitigate FortiBleed, remove management interfaces from the internet, force PBKDF2 re-hashing, enforce MFA, patch FortiOS, and monitor for stolen credentials.
These measures apply whether or not you currently appear in the dataset:
Remove management interfaces from the public internet
This is the highest-impact control. Restrict FortiGate admin access to trusted internal networks, VPN-only paths, or out-of-band management. Keep SSL VPN portals public only when there is a clear business need.
Force PBKDF2 hashing for all admin accounts
After upgrading FortiOS, require every administrator to log in at least once to trigger the PBKDF2 re-hash. On FortiOS 7.2.x/7.4.x, enable the relevant password-policy setting to purge residual SHA-256 hashes from old-password.
Enforce MFA everywhere
Apply multi-factor authentication to all admin and remote-access accounts. MFA neutralizes most stolen or cracked passwords.
Upgrade FortiOS and apply hardening guidance
Upgrade to the latest release and follow Fortinet's hardening best practices to close the CVEs that may have enabled config theft [5].
References
[1] H. Rock, “FortiBleed: 75,000 Fortinet Firewalls Compromised: Global Enterprises Exposed – Claim Your Ethical Disclosure,” Hudson Rock. Accessed: Jun. 24, 2026. [Online]. Available: https://www.hudsonrock.com/blog/fortibleed-75000-fortinet-firewalls-compromised-global-enterprises-exposed-claim-your-ethical-disclosure
[2] The Hacker News, “FortiBleed Targeted FortiGate Firewalls in 110 Million-Credential Harvesting Operation,” The Hacker News. Accessed: Jun. 24, 2026. [Online]. Available: http://thehackernews.com/2026/06/fortibleed-targeted-fortigate-firewalls.html
[3] “Website.” [Online]. Available: https://doublepulsar.com/fortibleed-75k-fortinet-firewalls-have-admin-passwords-cracked-60299faa65f8
[4] A. W. Labs, “Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries,” Arctic Wolf. Accessed: Jun. 24, 2026. [Online]. Available: https://arcticwolf.com/resources/blog/active-fortibleed-campaign-impacting-fortinet-devices-across-194-countries/
[5] C. Windsor, “Analysis of Reported Credential Compromise of FortiGate Devices,” Fortinet Blog. Accessed: Jun. 24, 2026. [Online]. Available: https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices
