FortiBleed Explained: How 73,932 Fortinet Firewalls Were Compromised in 2026

In mid-June 2026, security researchers disclosed one of the largest credential-compromise events targeting network perimeter devices in recent memory. A dataset containing validated administrator and SSL VPN credentials for tens of thousands of Fortinet FortiGate firewalls -- spanning 194 countries and virtually every major industry -- was found circulating among cybercriminal communities. The campaign was quickly named FortiBleed.

This article explains exactly what happened, how the attack was carried out, who is affected, and what administrators running Fortinet devices need to do right now.

What Is FortiBleed?

FortiBleed is the name given to a large-scale credential-compromise campaign affecting internet-exposed Fortinet FortiGate firewalls and SSL VPN gateways. Attackers harvested device configuration files, cracked stored credential hashes using offline GPU clusters, and assembled a searchable database of validated administrator and VPN credentials organized by country, sector, and organization revenue.

The result is not merely a data dump. As reported by SOCRadar and Arctic Wolf, the dataset functions as a ready-to-use targeting tool -- with credentials indexed in a way that allows threat actors to query by geography, vertical, or company size before launching intrusion attempts.

The Numbers

The 1.16 billion login attempts against FortiGate devices -- running in parallel with 2.1 billion brute-force attempts against MSSQL servers -- illustrate an operation at industrial scale, not opportunistic scanning.

How the Attack Worked

FortiBleed was not a single exploit. It was a convergence of known weaknesses, executed systematically. Here is the reconstruction based on researcher findings from Hudson Rock, Kevin Beaumont, SOCRadar, and Arctic Wolf.

Step 1: Configuration Harvesting

Attackers systematically extracted configuration files from internet-facing FortiGate devices. Researcher Kevin Beaumont noted that the dataset contains information -- including internal email addresses -- that is typically only present inside device configuration exports. This points to configuration-level exfiltration, not merely login-screen credential theft.

Step 2: Exploiting Known Vulnerabilities

The primary CVE linked to FortiBleed is CVE-2026-24858, a FortiCloud SSO SAML authentication bypass with a CVSS score of up to 9.8. Fortinet disclosed this vulnerability on January 27, 2026, and it was subsequently added to the U.S. CISA Known Exploited Vulnerabilities catalog. On devices with FortiCloud Single Sign-On enabled, an attacker could authenticate without valid credentials, create local administrative accounts for persistence, and exfiltrate configuration files. Additional CVEs referenced in related reporting include CVE-2026-35616 and, flagged separately for patching urgency, CVE-2026-25089 -- a FortiSandbox OS command injection vulnerability.

Step 3: The Hashing Root Cause

Older versions of FortiOS stored administrator credentials using a legacy SHA-256-based hashing scheme. SHA-256 is a fast cryptographic hash -- a property that is desirable for general-purpose integrity checking, but catastrophic for password storage. A modern GPU cluster can evaluate billions of SHA-256 candidates per second, making offline cracking of captured hashes practical even against passwords of typical enterprise complexity.

Fortinet addressed this by introducing PBKDF2-based password hashing in FortiOS versions 7.2.11, 7.4.8, and 7.6.1. PBKDF2 is deliberately slow and computationally expensive, making offline cracking attacks orders of magnitude harder. Devices running versions older than these thresholds retained the crackable SHA-256 hashes in their configurations.

Step 4: Offline Hash Cracking at Scale

Once configuration files were obtained, extracted password hashes were cracked offline using a GPU cluster -- reporting cited a multi-GPU Hashtopolis-style setup. Because the underlying scheme was SHA-256, cracking was fast and economical, particularly for passwords of typical enterprise complexity.

Step 5: Credential Stuffing from Infostealer Logs

In parallel, attackers tested credentials harvested from previous Fortinet-related breach datasets and from infostealer malware logs against exposed devices. The 1.16 billion login attempts across 320,777 FortiGate targets were run at scale; given that many organizations reuse credentials across systems, even a modest success rate across that volume yields thousands of valid entries.

Step 6: SSL VPN Hash Interception

SSL VPN authentication hashes were also intercepted during active sessions and cracked offline, extending the credential harvest beyond administrative interfaces to remote access users.

Step 7: Productization of the Dataset

The final step distinguishes FortiBleed from a generic data dump. Validated credentials were organized into a structured, searchable database indexed by country, industry sector, and company revenue. This transforms the breach from a commodity leak into a precision targeting instrument for follow-on intrusion operations.

Who Is Affected

The dataset spans 194 countries and virtually every sector: technology, telecommunications, manufacturing, e-commerce, logistics, government, financial services, and entertainment. Notable organizations whose domains appear in the public data include Samsung, Oracle, Foxconn, Comcast, AT&T, Siemens, Lenovo, Huawei, Spotify, Sony, Mercedes-Benz, Toyota, Chevron, FedEx, and ADP, among multiple government and telecommunications domains globally.

Appearance in the dataset indicates that credentials associated with those domains were exposed and validated. It does not, by itself, confirm that a follow-on intrusion of internal systems has already occurred -- but it should be treated as a serious indicator of compromise requiring immediate investigation.

Is FortiBleed a Zero-Day?

As of the time of disclosure, Fortinet had not confirmed a new, previously unknown vulnerability specific to FortiBleed. The most supported interpretation among researchers is a convergence: known CVEs that went unpatched on many devices (particularly CVE-2026-24858), legacy SHA-256 password hashing on older FortiOS versions, and recycled credentials already circulating from infostealer campaigns and prior breaches.

The exact method by which configuration files were obtained has not been officially confirmed. Researchers note it is unclear whether configs were exfiltrated through the disclosed CVEs, an undisclosed flaw, infostealer-harvested credentials, or a combination of all three. Administrators should not wait for confirmation of a novel zero-day before acting -- the known attack surface is already sufficient to justify immediate response.

How to Check and Respond

If your organization runs any internet-facing Fortinet FortiGate firewall or SSL VPN gateway, treat your device as potentially affected until proven otherwise. The following checklist reflects guidance from CISA, Arctic Wolf, SOCRadar, and independent researchers.

1. Immediately reset all administrative and SSL VPN credentials -- prioritize internet-exposed devices and any device that may have been involved in a previous credential exposure.
2. Enforce multi-factor authentication (MFA) on all administrative and remote-access accounts.
3. Restrict management interface access -- firewall management should never be reachable from the public internet. Limit access to trusted internal networks or a dedicated management VLAN.
4. Upgrade FortiOS to version 7.2.11, 7.4.8, 7.6.1, or later to ensure PBKDF2 password hashing is in use.
5. After upgrading, require every administrator to log in at least once -- this triggers re-hashing of their stored credentials with PBKDF2. Until they do, old SHA-256 hashes may persist in the configuration.
6. On FortiOS 7.2.x and 7.4.x, enable the login-lockout-upon-weaker-encryption setting in the system password policy to force removal of residual SHA-256 hashes.
7. Audit firewall, admin, and VPN logs for suspicious logins, off-hours access, and unexpected local administrator accounts -- the latter being a key persistence indicator when CVE-2026-24858 was exploited for initial access.
8. Patch related CVEs, including CVE-2026-24858 and CVE-2026-25089.
9. Monitor for employee credentials in infostealer logs -- breach intelligence services can alert when credentials appear in harvested malware logs before they are weaponized against your organization.

The Broader Lesson

FortiBleed is less a Fortinet-specific story than a demonstration of a repeatable attack pattern that will recur across other vendors and platforms. The chain is consistent: an internet-exposed administrative interface, credentials already circulating in infostealer markets, weak or legacy password hashing, and absent MFA. Each link in that chain is independently exploitable; all four together make a campaign like FortiBleed operationally straightforward for a well-resourced threat group.

Any organization running an internet-facing management interface -- whether a firewall, VPN concentrator, hypervisor, database server, or server control panel -- is exposed to the same fundamental chain. The durable defenses are vendor-neutral: keep management interfaces off the public internet, enforce MFA everywhere, rotate credentials on a defined schedule, use modern slow password hashing (PBKDF2, bcrypt, or Argon2), patch promptly, and monitor for credential exposure through breach intelligence.

Frequently Asked Questions

What is FortiBleed?

FortiBleed is a credential-compromise campaign in which attackers extracted configuration files from tens of thousands of internet-facing Fortinet FortiGate firewalls and SSL VPN gateways, cracked stored password hashes offline using GPU clusters, and assembled a validated, searchable database of administrator and VPN credentials. The resulting dataset covers 73,932 unique firewall URLs across 194 countries and was found circulating among cybercriminal communities in mid-June 2026, with major disclosures on June 17, 2026.

How many devices were affected by FortiBleed?

The dataset covers 73,932 unique compromised firewall URLs. Researchers at Hudson Rock and Kevin Beaumont estimate the number of distinct affected devices at approximately 75,000 -- roughly 50% of all internet-facing Fortinet firewalls indexed by Shodan at the time of disclosure. SOCRadar independently verified more than 30,791 working administrative credentials within the dataset. The geographic spread covers 194 countries and approximately 21,600 domains.

Is FortiBleed a zero-day vulnerability?

No new zero-day specific to FortiBleed has been officially confirmed by Fortinet as of disclosure. The most supported interpretation among researchers is a convergence of known, disclosed CVEs (especially CVE-2026-24858) that went unpatched on many devices, combined with older FortiOS versions using crackable SHA-256 password hashing and recycled credentials from infostealer campaigns. Administrators should act immediately regardless of zero-day confirmation.

Which CVEs are linked to FortiBleed?

CVE-2026-24858 is the primary CVE cited -- a FortiCloud SSO SAML authentication bypass with a CVSS score up to 9.8, disclosed by Fortinet on January 27, 2026, and added to the CISA Known Exploited Vulnerabilities catalog. CVE-2026-35616 is also referenced in related reporting. CVE-2026-25089, a FortiSandbox OS command injection vulnerability, is flagged separately for urgent patching in the same response guidance.

How do I know if my Fortinet device is affected?

If your device is internet-facing and runs FortiOS older than version 7.2.11, 7.4.8, or 7.6.1, assume it may be affected and act accordingly. Rotate all administrative and VPN credentials immediately, enable MFA, restrict management interface access to trusted internal networks, and review logs for signs of unauthorized access or unexpected local administrator accounts. Upgrading to a patched FortiOS version and completing the post-upgrade re-login procedure to trigger PBKDF2 re-hashing is mandatory.

How do I protect against FortiBleed?

The core protective steps are: reset all credentials immediately; enforce MFA on every administrative and remote-access account; restrict management interface access to internal trusted networks only; upgrade FortiOS to 7.2.11, 7.4.8, 7.6.1 or later; require all administrators to log in post-upgrade to re-hash stored credentials with PBKDF2; enable the login-lockout-upon-weaker-encryption policy flag on 7.2.x and 7.4.x; audit logs for suspicious logins and unexpected local accounts; patch CVE-2026-24858 and CVE-2026-25089; and monitor for employee credentials appearing in infostealer breach feeds.

Key Takeaways

• Scale: 73,932 unique FortiGate URLs, 194 countries, 30,791+ verified working credentials -- FortiBleed ranks among the largest perimeter-device credential events on record.
• Credential reuse and infostealers amplify impact: 1.16 billion credential-stuffing attempts across FortiGate targets demonstrate how previously leaked and infostealer-harvested data is being industrialized against perimeter devices.
• The SHA-256-to-PBKDF2 transition is the technical root cause: FortiOS 7.2.11, 7.4.8, and 7.6.1 replaced crackable fast SHA-256 hashing with PBKDF2. Devices not yet upgraded retain crackable hashes even after the initial breach is detected.
• MFA and management interface isolation are non-negotiable: FortiBleed-style campaigns cannot succeed at scale against management interfaces that are unreachable from the public internet and require multi-factor authentication.
• The pattern generalizes: Internet-exposed management interface plus legacy password hashing plus credential reuse plus absent MFA is a repeatable attack formula that applies to any vendor's perimeter device or administrative interface. The hardening principles are universal.