FortiBleed Exposes Global Enterprises: Critical Steps to Secure Your FortiGate
A verified database of working admin credentials for 75,000+ Fortinet FortiGate firewalls is circulating in criminal markets. Here’s the definitive breakdown and the exact steps your security team must take this week.
Somewhere in your security team’s inbox right now, there may be an alert about FortiBleed and if there isn’t, that’s arguably the bigger problem. In the second week of June 2026, independent security researcher Volodymyr “Bob” Diachenko stumbled across something unusual: an exposed server sitting openly on the public internet, belonging not to a legitimate organisation, but to a threat actor. What it contained was staggering.
A verified, searchable database. Administrator usernames and cracked passwords for over 75,000 Fortinet FortiGate firewalls and SSL VPN gateways, spanning 194 countries, indexed by industry sector and even by company revenue. Not theoretical vulnerabilities. Not proof-of-concept exploits. Working credentials. Keys that still opened doors.
We’ve been tracking this campaign closely since it broke, and we want to cut through the noise. This piece explains exactly what FortiBleed is, why it succeeded at scale, which organisations and FortiOS versions are affected, and what your team needs to do in plain language, in the right order.
What Is FortiBleed? The Fortinet Credential Exposure Explained
The name is deliberately evocative of Heartbleed, the 2014 OpenSSL vulnerability that shook the internet. But the comparison only goes so far. FortiBleed is not a single software flaw, and there is no one patch that makes it go away. That distinction matters, because organisations waiting for a Fortinet advisory that says “apply this update and you’re safe” are going to be waiting a long time.
What FortiBleed actually represents is a sophisticated, months-long credential harvesting operation. According to SOCRadar’s Threat Research Unit, which coined the term and first published detailed analysis, the campaign had been running since at least February 2026. Their researchers ultimately identified over 150 operational servers tied to the operation and a final dataset of 86,644 confirmed working credentials though figures across vendors range from roughly 74,000 (CISA) to that higher estimate as new validation occurs.
The campaign succeeded because it combined four independently exploitable weaknesses at industrial scale.
1. Credential Reuse From Prior Breaches
Attackers pulled usernames and passwords from years of accumulated infostealer malware logs and previous breach datasets, then ran automated scripts testing every combination against every reachable Fortinet device. The sheer volume billions of authentication attempts across hundreds of thousands of targets meant that even a low success rate produced an enormous harvest.
2. Weak Legacy Password Hashing in FortiOS
This is the technical detail that matters most for understanding your exposure. Fortinet migrated to the stronger PBKDF2 (Password-Based Key Derivation Function 2) hashing algorithm in FortiOS versions 7.2.11, 7.4.8, and 7.6.1. Devices running those versions or higher store new credentials securely. The problem is what happens on upgrade: existing administrator passwords remain in the older SHA-256 format until that administrator physically logs in again post-upgrade. A device can be fully patched and still store admin credentials in the weaker format if nobody has logged in since the upgrade.
As Arctic Wolf notes in their FortiBleed advisory, many organisations almost certainly fell into exactly this trap patched firmware, legacy credential storage, crackable hashes.
3. SSL VPN Hash Interception and GPU Cracking
Where credential reuse failed, attackers intercepted SSL VPN authentication hashes during the login handshake and cracked them offline on a dedicated 45-GPU cluster. This is not a trivial operation it requires significant infrastructure but it is well within the reach of organised criminal groups with nation-state-level resources, which is precisely what researchers believe is behind this campaign.
4. The Linked CVE: CVE-2026-24858
For FortiGate devices with FortiCloud single sign-on enabled, attackers exploited a separate authentication bypass vulnerability CVE-2026-24858 listed on CISA’s Known Exploited Vulnerabilities catalogue. This allowed them to authenticate without valid credentials, create persistent local admin accounts, and exfiltrate configuration files. If your organisation uses FortiCloud SSO and hasn’t patched this, it belongs at the very top of your remediation list.
Which Organisations Are Affected by FortiBleed?
The short answer is: more than you might expect, and possibly yours. Researchers estimate the dataset covers roughly half of all internet-facing Fortinet FortiGate devices globally. The named organisations in the circulating dataset include Samsung, Siemens, Foxconn, Oracle, Accenture, DHL, Infosys, PwC, Chevron, FedEx, Comcast and, according to multiple researcher reports, Fortinet itself. A Turkish NATO defence contractor suffered confirmed classified document exfiltration.
India and the United States together account for nearly a third of all entries in the dataset. Hudson Rock has published a lookup tool allowing organisations to check whether their domain appears in the exposed data. Check it now, before you finish reading this article. But critically a negative result does not mean you’re safe. Dataset validation is still ongoing, and the full scope of circulation in criminal markets is unknown.
Affected FortiOS Versions at a Glance
Versions at elevated risk (legacy SHA-256 credential storage possible):
- FortiOS 7.2.10 and earlier
- FortiOS 7.4.7 and earlier
- FortiOS 7.6.0 and earlier
- Any version where administrators have not logged in since upgrading to a PBKDF2-capable release
Better posture (PBKDF2 for new credentials):
- FortiOS 7.2.11+
- FortiOS 7.4.8+
- FortiOS 7.6.1+
- FortiOS 8.0 (all builds)
Note: Being on a PBKDF2-capable version does not guarantee safety if admin passwords have not been reset since migration. Firmware version and credential state are two separate things that must both be addressed.
Why FortiBleed Is a Boardroom-Level Threat Not Just an IT Problem
There’s a tendency in organisations to treat firewall incidents as infrastructure problems that the network team sorts out. FortiBleed is different, and the boardroom needs to understand why.
A firewall is the most trusted device on your network. It sits at the perimeter, it inspects all traffic, and every other security control downstream of it operates on the assumption that the perimeter is intact. When an adversary quietly takes control of that device, the consequences cascade in ways that are genuinely difficult to detect.
A compromised firewall is worse than no firewall at all because your team keeps trusting it. Logging can be silently weakened from inside. Alerting rules can be modified. Segmentation can be bypassed. And none of this looks anomalous from inside the network, because the firewall itself is the source of truth.
In confirmed FortiBleed cases, attackers didn’t stop at the perimeter. They pivoted directly into internal Active Directory environments, harvested NTLM and Kerberos hashes by using the compromised firewall as a packet-sniffing post inside the network, and moved laterally through corporate infrastructure. As Huntress confirmed in their incident analysis, this technique doesn’t trigger traditional malware or behavioural alerts it looks like normal traffic, because it flows through a trusted device.
Three dynamics make this particularly dangerous for mid-market and enterprise organisations:
- Supply-chain cascade: Managed service providers often deploy near-identical FortiGate configurations across dozens of clients. One harvested credential pattern can ripple across many networks simultaneously.
- Revenue-indexed targeting: The FortiBleed dataset is organised by company revenue, which is exactly the intelligence ransomware affiliate groups use to select and prioritise high-value victims. Larger organisations in this dataset face heightened ransomware risk over the next 60–90 days.
- The fragile perimeter: The perimeter is only as strong as the credential protecting it. In a world saturated with infostealer-harvested data, that credential has never been more exposed.
FortiBleed Is an Identity Failure Not Just a Firewall Problem
Strip away the Fortinet branding and what remains is a textbook illustration of how identity security failures produce network-wide breaches. The kill chain that FortiBleed exploited is entirely vendor-agnostic:
Exposed management interface + recycled credentials + weak legacy hashing + absent MFA = full compromise. Every link in that chain is an identity and access failure.
Organisations that had already implemented a mature privileged access management (PAM) programme credential vaulting, automated rotation, session isolation, just-in-time (JIT) access, and phishing-resistant MFA were structurally far harder to compromise even with an exposed FortiGate. A leaked password from an infostealer log doesn’t help an attacker much when that password is rotated automatically every 30 days, never leaves the vault in plaintext, and requires a hardware token to actually use.
That is the difference between a vulnerability that exists and a breach that happens. And it’s the reason why FortiBleed will recur under different vendor names, across different platforms until organisations stop treating privileged access as an afterthought.
The 2026 Field Effect Threat Outlook Report makes this point clearly: the majority of incidents today involve identity abuse stolen credentials, session hijacking, MFA fatigue, SSO bypass not novel malware or zero-day exploitation. Attackers take the path of least resistance, and for most organisations, that path still runs straight through unmanaged privileged access.
FortiBleed Response Checklist: Steps to Take Right Now
If your organisation runs any internet-facing Fortinet FortiGate firewall or SSL VPN gateway, treat it as potentially affected unless you can demonstrate otherwise. Work through this list in order sequence matters.
Immediate (Do Today)
- Rotate every credential immediately. Reset all Fortinet administrator and VPN user passwords. Password complexity is irrelevant if the original password has already leaked and been cracked.
- Terminate all active sessions. Kill existing SSL VPN and management sessions to evict anyone already inside.
- Check your exposure. Use the Hudson Rock lookup tool to see whether your domain appears in the circulating dataset. Treat any match as confirmed exposure requiring a full incident response engagement.
Within 48 Hours
- Force the PBKDF2 hash upgrade. After any FortiOS upgrade, require every administrator to log in at least once to trigger the migration to PBKDF2. If that’s not immediately feasible, manually reset remaining admin passwords using a super_admin account.
- Enforce phishing-resistant MFA. Deploy hardware-token or FIDO2-based MFA across all external gateways and admin interfaces. This is the single most effective control against the credential stuffing and brute-force techniques documented in FortiBleed.
- Restrict management interface access. Apply local-in policies so the admin panel is reachable only from trusted internal IP ranges. If you don’t use FortiCloud SSO, disable it and patch CVE-2026-24858 regardless.
This Week
- Conduct threat hunting across your logs. Audit FortiGate, SSL VPN, Active Directory, and domain controller logs for off-hours logins, unfamiliar geographies, unexpected local admin accounts, altered firewall rules, and anomalous lateral movement patterns.
- Patch the linked CVEs, including CVE-2026-24858 and any other outstanding Fortinet advisories.
- Upgrade FortiOS. Move to 7.2.11+, 7.4.8+, 7.6.1+, or 8.0 to ensure new credentials are stored with PBKDF2.
- Activate your incident response plan. If your domain appears in the dataset, treat it as a confirmed breach from the outset. Engage professional IR support early waiting until damage becomes visible is the most expensive approach.
How Hassium Cyber Solutions Can Help
At Hassium Cyber Solutions, identity and privileged access security is the core of what we do. FortiBleed is precisely the kind of event our work is designed to prevent and to contain when prevention came too late.
We help organisations across three phases:
- Immediate FortiBleed response emergency credential rotation, session termination, configuration review, log-based threat hunting, exposure assessment, and incident coordination.
- PAM programme design and deployment enterprise CyberArk and BeyondTrust implementations: credential vaulting, automated rotation, session isolation, and just-in-time access so a single leaked password never again becomes a network-wide breach.
- Perimeter and identity hardening MFA enforcement, management-interface restriction, continuous attack-surface monitoring, and zero-trust access design.
- Long-term resilience incident response planning, tabletop exercises, red team engagements, and ongoing managed monitoring.
The keys to your network are only as safe as the system protecting them. Let’s make sure yours are locked in a vault not sitting exposed in a configuration file.
Get a FortiBleed Exposure Review
Frequently Asked Questions (FAQs)
Is FortiBleed a new zero-day vulnerability in Fortinet products?
No. FortiBleed is not a single CVE. It is a credential harvesting campaign that exploited credential reuse, legacy password hashing, SSL VPN hash interception, and one specific authentication bypass vulnerability (CVE-2026-24858) in combination. Fortinet characterises the exposure as recycled data combined with brute-force activity, though researchers note that many affected devices run recent firmware, suggesting active current collection.
Our FortiGate is fully patched. Are we safe?
Not necessarily. Firmware version and credential state are independent variables. A fully patched device running FortiOS 7.4.8 can still store admin passwords in the weaker SHA-256 format if administrators haven’t logged in since the upgrade. Patch status does not guarantee credential security you must also force the PBKDF2 migration by having all admins log in post-upgrade.
We didn't appear in the Hudson Rock lookup. Can we stand down?
We wouldn’t recommend it. Dataset validation is ongoing, the full scope of circulation in criminal markets is unknown, and the lookup tools index only confirmed entries not every affected device. Use a clean result as one positive signal among several, not as a clean bill of health.
What should we do if we confirm we're in the dataset?
Treat it as a confirmed breach immediately. Execute credential rotation and session termination as described above, preserve logs for forensic purposes, engage your cyber insurance provider, and bring in professional incident response support. The forensic window the ability to determine what was accessed and when closes quickly.
How does this connect to our PAM programme?
Directly. Organisations with mature PAM in place automated credential rotation, vaulted secrets, JIT access, and strong MFA were significantly harder targets even with an exposed firewall. If FortiBleed exposed a gap in your privileged access programme, now is the time to close it.
