FortiBleed: 75,000 Firewalls Exposed, and the One Control That Stops It

In mid-June 2026, security researchers began tracking a large-scale campaign, nicknamed FortiBleed, that exposed working administrator and VPN credentials on tens of thousands of internet-facing Fortinet FortiGate firewalls. If a firewall is the front door to your network, this is a campaign that quietly copied a lot of keys.

What actually happened

This was not a single dramatic zero-day. Attackers systematically pulled configuration files from internet-exposed FortiGate devices and cracked the stored credential hashes offline. Older FortiOS versions stored administrator passwords with a legacy SHA-256 scheme that is comparatively fast to crack; Fortinet has since moved to a stronger PBKDF2-based hash (in FortiOS 7.2.11, 7.4.8, and 7.6.1). Where that older storage was still in place, cracked hashes turned into usable admin and SSL-VPN logins.

The scale is the story. Researchers verified working credentials on roughly 30,000 devices, with broader estimates near 75,000, about half of all internet-facing Fortinet firewalls, across 194 countries. Researchers were clear this was a credential-cracking campaign, not a Fortinet zero-day, there is no single CVE behind FortiBleed. The danger is simpler: valid administrator and VPN logins, harvested at scale, that let attackers walk straight in and persist inside networks.

A leaked firewall credential is not a "firewall problem." It's a domain-admin problem, a ransomware problem, and, if you carry a policy, a cyber-insurance-claim problem.

Why this should matter to you even if you don't run Fortinet

Strip away the vendor name and FortiBleed is a textbook example of the failure mode underwriters care about most: an internet-facing administrative service, protected by a password alone, with no second factor in the way. The remediation guidance researchers published reads almost word-for-word like a cyber-insurance security questionnaire:

• Reset all administrative and VPN credentials.
• Enforce multi-factor authentication on every administrative account.
• Restrict firewall management interfaces to trusted internal networks, don't expose them to the open internet.
• Upgrade to a FortiOS version that uses stronger password hashing.
• Keep edge devices patched against actively exploited CVEs.

The control that would have blunted it

MFA on remote access and administrative logins. A cracked password is worthless to an attacker who also needs a second factor they don't have. This is exactly why cyber insurers now treat MFA on VPN, RDP, and admin accounts as table stakes, not a nice-to-have, but a question you must answer "yes" to before they'll write or renew a policy. FortiBleed is the underwriting concern made real: tens of thousands of organizations whose single-factor edge just became a published credential.

If you're not certain you could answer "yes, MFA is enforced on all remote access and admin accounts, and our management interfaces aren't internet-exposed," that uncertainty is precisely what a carrier's questionnaire is designed to surface.

Running Microsoft 365 or cloud infrastructure behind that firewall? The same MFA-and-exposure logic applies inside your tenant and cloud accounts, our M365 Hardening and AWS/Azure checklists cover those.