FortiBleed: Inside the 73,000-Firewall Credential Leak

A credential leak now circulating as FortiBleed has exposed verified administrator and SSL VPN credentials for 73,932 unique Fortinet FortiGate firewall URLs across 194 countries. The dataset, surfaced on 17 June 2026 by security researcher Bob Diachenko and verified by Hudson Rock, SOCRadar, Arctic Wolf, and Kevin Beaumont, touches 21,632 unique domains and contains over 30,791 confirmed working credentials. Per Shodan data referenced by Beaumont, this is roughly half of every internet-accessible Fortinet firewall worldwide.

Affected organisations read like an index of the Fortune Global 500: Chevron, Samsung, Foxconn, Comcast, AT&T, Mercedes-Benz, Toyota, Sinopec, State Grid, Siemens, Lenovo, PwC, Accenture, Oracle, and FedEx all appear in the dataset, alongside government agencies and a Turkish NATO defence contractor reportedly fully breached with classified documents exfiltrated.

This is a technical breakdown for SOC teams, network engineers, and security leaders: what FortiBleed is, what it isn't, which CVEs are relevant, how the attack chain works, how to check if your devices are affected, and the remediation you should be running right now. Sources consolidated as of 18 June 2026 include BleepingComputer, The Register, SOCRadar, Arctic Wolf, SentinelOne, CISA, the NVD, and Fortinet's own statements. Where Fortinet and independent researchers disagree, both positions are named.

1. What FortiBleed Is — and What It Is Not
2. The Scale and Scope
3. How the Attack Chain Actually Works
4. The CVE Context That Matters
5. How to Check If You Are Affected
6. Immediate Remediation Steps
7. What This Means for Perimeter Security

What FortiBleed Is — and What It Is Not

FortiBleed is a credential-compromise campaign, not a single CVE. Despite the name's echo of Heartbleed, no new Fortinet zero-day has been confirmed as the source. The dataset is the operational output of a large-scale credential-harvesting operation running for months against internet-exposed Fortinet management and VPN interfaces.

Three positions exist on what produced the dataset, and they matter for triage:

Fortinet's official position (17 June 2026): the data represents "a resharing of data from previous incidents, as well as bruteforcing of credentials, and is not related to any recent incident or advisory." Fortinet directs customers to its March 2026 credential hygiene guidance and states organisations following routine best practices "face minimal risk."

Independent researcher position (Beaumont, Hudson Rock, Diachenko, SOCRadar): the data is legitimate, many credentials are still valid, and many of the affected devices are running fairly recent patches. Some exposed passwords are long and complex, suggesting extraction from device configuration files rather than guessing implying compromise beyond simple credential stuffing.

SOCRadar's position: no evidence of a new Fortinet zero-day, but the campaign convergence point known CVEs left unpatched on some devices, legacy SHA-256 password hashing on older FortiOS, and recycled credentials from previous leaks produced compromises across organisations that thought they were defending well.

The honest framing: FortiBleed is real, the credentials are valid for many listed organisations, and the source of the configuration data is still ambiguous. Whether through a previously undisclosed flaw, exploitation of known but unpatched CVEs, or compromise via credentials harvested from infostealer logs and previous breaches, the practical effect is the same. The dataset exists. Attackers have it. Many credentials still work. You have to act.

The Scale and Scope

The numbers, consolidated across reporting:

• 73,932 unique FortiGate firewall URLs in the dataset
• 21,632 unique organisational domains affected
• 194 countries with at least one affected device
• 30,791 confirmed working credentials verified by SOCRadar
• 1.16 billion credential-stuffing attempts conducted against 320,777 FortiGate targets
• 2.1 billion parallel attempts against 163,650 Microsoft SQL Server systems
• 45-GPU Hashtopolis cluster used by the threat group to crack SSL VPN authentication hashes offline

Sector breakdown (from SOCRadar analysis):

• Telecommunications: most affected sector, 5,616 entries
• Government: 591 entries across 111 unique government domains
• IT services, financial services, healthcare, education, energy
• Manufacturing multiple Fortune Global 500 manufacturers

Geographic concentration: India and the United States together represent nearly one-third of the dataset. SOCRadar noted victim selection appeared "heavily weighted toward organisations in NATO member countries" and flagged the presence of defence-industry VPN credentials, suggesting espionage motivations alongside the financially-motivated brute-force component.

Confirmed full compromises: Diachenko reports the threat group produced full network compromises at organisations across Japan, Taiwan, Vietnam, Iraq, and Turkey. The Turkish NATO defence contractor breach reportedly resulted in exfiltration of classified defence documents the most significant confirmed downstream impact disclosed so far.

The threat group itself is described by Diachenko as Russian-speaking and multi-operator. No single APT designation has been publicly assigned, and attribution remains preliminary.

How the Attack Chain Actually Works

The reconstructed attack chain combines four phases, each of which would individually be defensible but which compound when the basic controls are missing.

Phase 1 — Internet-wide reconnaissance. The threat group conducts continuous scanning of public IP space for exposed Fortinet appliances primarily FortiGate SSL VPN endpoints and administrative interfaces directly reachable on the internet. Beaumont's analysis of the dataset against Shodan data indicates that most of the affected devices have their management interfaces exposed to the public internet, which is the single largest contributing factor to the campaign's success.

Phase 2 — Credential stuffing from curated wordlists. Rather than random brute-force, the attackers test credentials from two specific pools:

• Historical Fortinet leaks: the 2021 leak of approximately 500,000 FortiGate VPN account credentials, the Belsen Group dump of 15,000 device configurations released in January 2025 obtained through exploitation of CVE-2022-40684, and other public dumps.
• Infostealer logs: credentials harvested from compromised employee endpoints by infostealer malware (Lumma, RedLine, and others), which capture browser-stored corporate VPN credentials.

The 1.16 billion credential attempts represent the brute-force scale of this phase. Many were unsuccessful, but enough succeeded that the threat group built a curated dataset of verified working credentials.

Phase 3 — SSL VPN hash interception and offline cracking. For devices not vulnerable to credential stuffing, the threat group employed a more sophisticated technique: intercepting SSL VPN authentication hashes during the login handshake, then cracking them offline using a 45-GPU Hashtopolis cluster. This phase exploits a structural weakness in older FortiOS versions: administrator passwords were stored using SHA-256 with salt rather than a slow modern hashing algorithm. SHA-256 is fast to compute, which means it's also fast to brute-force at GPU scale.

Fortinet did eventually introduce PBKDF2-based password hashing for administrator credentials in FortiOS 7.2.11, 7.4.8, and 7.6.1. The critical detail many defenders missed: when upgrading from earlier versions, existing administrator passwords remain stored as SHA-256 hashes until the corresponding administrator successfully logs in following the upgrade. Most organisations upgraded the firmware but never re-logged-in administrators to trigger re-hashing. The credentials stayed in the older, faster-to-crack format. The 45-GPU cluster did the rest.

Phase 4 — Self-sustaining sniffer loop. This is the part of the campaign that elevates it from "credential stuffing operation" to something more concerning. Once a device is compromised, attackers deploy network sniffers on the firewall itself, monitoring traffic passing through the appliance. Any credentials flowing across the network whether to internal services, third-party APIs, or further VPN tunnels are captured and fed back into the credential pool. The compromised firewall becomes a credential-harvesting platform that increases the size of the attack base over time.

Compromised devices then enable pivoting into internal Active Directory environments via the network position the firewall sits in. Once domain credentials are obtained, the attack pivots from perimeter compromise to internal compromise. SentinelOne's separate investigation in early 2026 documented the same pattern: FortiGate appliances compromised in November 2025 were used to create local administrator accounts named "support", which then traversed all zones without restriction and persisted for months before further activity was detected.

The CVE Context That Matters

Several CVEs from the past 18 months are relevant to FortiBleed even though none is confirmed as the singular source. Patch state on these vulnerabilities is the first thing to check.

The critical lesson from CVE-2026-24858: organisations running the latest FortiOS firmware against the December 2025 SSO bypass were still compromised in January 2026 because a second authentication bypass existed in the same attack surface that Fortinet had not yet identified. Patch state at a single point in time is not equivalent to safety. This is part of why some FortiBleed victims appear in the dataset despite running recent firmware versions.

How to Check If You Are Affected

Three checks, in order of priority:

1. Free lookup tool. Hudson Rock published a free FortiBleed lookup tool at breached.company where you can check whether your organisation's domain appears in the dataset. This is the fastest first triage. A clean result does not prove safety it indicates your specific domain wasn't in the harvested sample but a hit confirms you need to assume compromise.

2. Configuration audit on every FortiGate device. Log into each FortiGate appliance and run the following checks from the CLI. Look for anything unexpected.

# List all administrator accounts — watch for unfamiliar names,
# especially "support", "admin2", or anything with elevated privileges
show system admin

# List all local user accounts
show user local

# Review all firewall policies — look for newly created policies
# that allow traversal across zones or wide-open ranges
show firewall policy

# Active SSL VPN sessions — check for sessions from unexpected geographies
diagnose vpn ssl list

# Recent administrative login history
execute log filter category 1
execute log display

The specific IOC SentinelOne documented in its February 2026 investigation: a local administrator account named "support" created in November 2025 on compromised devices, with four firewall policies attached that allowed the account to traverse all zones unrestricted.

3. Active Directory audit. Even if your FortiGate looks clean, the campaign's lateral movement pattern means an AD audit is essential. Specifically: look for unexpected service accounts created in late 2025 or early 2026, password changes on existing service accounts that weren't part of normal rotation, and Kerberos ticket anomalies suggesting credential-based lateral movement.

If you find any of these indicators, treat the FortiGate device as fully compromised. Do not simply rotate the password the threat group's pattern includes deploying persistent sniffers and creating backdoor accounts that survive credential rotation.

Immediate Remediation Steps

The ordered checklist for any organisation running internet-facing Fortinet devices. Treat steps 1-5 as urgent within 24 hours. Steps 6-10 within the week.

1. Rotate every credential on every Fortinet device. Administrator passwords, VPN account passwords, API keys, anything stored on the device or in its configuration. Use long, unique passwords generated by a password manager not memorable patterns.

2. Enforce MFA on every administrative and remote-access account. FIDO2 tokens or certificate-based authentication if you can implement them phishing-resistant MFA renders stolen credentials ineffective even if attackers possess valid usernames and passwords. If you only have TOTP available, deploy that now and upgrade to phishing-resistant MFA in the following quarter.

3. Restrict management interface access to internal trusted networks only. This is the single largest defensive lever available. If your FortiGate management interface is reachable from the public internet, that is the root cause of the attack surface FortiBleed exploited. Move administration onto a dedicated management VLAN or a VPN concentrator, and remove public exposure of the admin interface entirely.

4. Upgrade FortiOS to 7.2.11, 7.4.8, 7.6.1, or later. These are the versions that introduce PBKDF2-based password hashing for administrator credentials. Critically, upgrade alone is not enough see step 5.

5. Force every administrator to log in after the upgrade. Existing administrator passwords remain stored as SHA-256 hashes until each administrator logs in successfully following the upgrade. Until that login happens, the credential remains vulnerable to GPU-accelerated cracking even on a fully-patched device. Either schedule a forced re-login across all admins, or use a super_admin account to manually update the passwords of remaining administrators.

6. Enable the login-lockout-upon-weaker-encryption policy flag on FortiOS 7.2.x and 7.4.x. This prevents accounts with SHA-256-hashed passwords from successfully authenticating until they are rotated through to PBKDF2.

7. Apply all relevant Fortinet CVE patches. Particularly CVE-2026-24858 (the FortiCloud SSO bypass), CVE-2025-59718 and CVE-2025-59719 (SAML SSO bypass), and CVE-2026-35616 and CVE-2026-21643 if you run FortiClient EMS.

8. Audit all Active Directory environments accessible from the affected FortiGate's network segment. Look for unauthorised service accounts, unexpected password changes on existing accounts, Kerberos anomalies, and lateral movement indicators. If FortiGate has provided VPN access to AD-joined hosts, assume AD has been touched.

9. Set up monitoring for employee credentials in infostealer breach feeds. Services like Hudson Rock, IntelX, and others can alert you when employee credentials appear in newly-released infostealer dumps. This is the primary source of credentials feeding the next iteration of campaigns like FortiBleed.

10. Consider replacement, not just rotation, for any device you suspect was compromised. If your FortiGate appeared in the dataset and you cannot rule out attacker persistence, the safer remediation is a full device replacement with credentials, certificates, and configuration rebuilt from scratch not just password rotation on the existing device.

What This Means for Perimeter Security

FortiBleed isn't isolated. It's the third major Fortinet credential exposure in five years the 2021 leak of 500,000 VPN accounts, the 2025 Belsen Group dump of 15,000 device configurations, and now 73,932 firewalls in 2026. Each round demonstrates that internet-exposed network appliances with administrative interfaces remain the highest-value compromise targets in enterprise environments.

The architectural lesson: traditional SSL VPN with internet-exposed management interfaces is structurally unfit for 2026 threat models. Credential reuse from infostealer logs, GPU-accelerated offline hash cracking, and self-sustaining sniffer loops on compromised devices make the perimeter VPN model insecure regardless of vendor. The same playbook scan, stuff, sniff, feed will be applied against Cisco AnyConnect, Palo Alto GlobalProtect, SonicWall, and Pulse Secure deployments in the next 12-18 months unless those deployments are architecturally hardened.

Zero Trust Network Access (ZTNA) replaces the implicit-trust perimeter model with continuous authentication and authorisation per-resource. Device posture checks, identity-bound access, and short-lived session tokens collapse the attack surface FortiBleed exploited. ZTNA has its own attack surfaces it's not a complete answer but it removes the structural weakness that has now produced three Fortinet incidents at this scale.

For organisations still operating SSL VPN, the priority order is non-negotiable: management interfaces off the public internet, phishing-resistant MFA on every account, modern password hashing verified through admin re-login, rotated credentials on schedule, and monitored breach intelligence feeds. If your organisation appears in the FortiBleed dataset, the assumption is that compromise has already occurred and that incident response not just credential rotation is required.

Related reading:

• LLM Penetration Testing: How to Test AI Applications
• Penetration Testing Cost Guide 2026
• NIS2 Penetration Testing Requirements
• Assumed Breach Penetration Testing Guide

Frequently Asked Questions

Is FortiBleed a Fortinet vulnerability or a credential leak?

FortiBleed is a credential-compromise campaign, not a single vulnerability. No new Fortinet zero-day has been confirmed as the source of the dataset. Fortinet's official position is that the data is a resharing of credentials obtained through previous incidents and brute-force attacks. Independent researchers including Kevin Beaumont, Hudson Rock, and SOCRadar have confirmed many credentials remain valid and that some affected devices were running recent patches, suggesting a more complex origin than simple credential stuffing alone.

How do I know if my organisation is in the FortiBleed dataset?

Hudson Rock published a free lookup tool at breached.company where you can check whether your domain appears in the dataset. A clean result indicates your specific domain wasn't in the harvested sample but does not prove safety. A hit confirms you need to assume compromise and run the full remediation checklist immediately.

Which Fortinet CVEs are related to FortiBleed?

Several CVEs from 2025-2026 are relevant though none is confirmed as the singular source: CVE-2026-24858 (CVSS 9.4 FortiCloud SSO bypass, on CISA KEV), CVE-2025-59718 and CVE-2025-59719 (CVSS 9.8 SAML SSO bypass), CVE-2026-35616 (CVSS 9.1 FortiClient EMS unauthenticated API bypass), and CVE-2026-21643 (FortiClient EMS SQL injection). The historical CVE-2022-40684 was the source of the 2025 Belsen Group configuration dump that fed earlier credential pools.

What should I do right now if my FortiGate is internet-exposed?

In order of urgency: rotate every administrator and VPN credential, enforce phishing-resistant MFA, restrict management interface access to internal trusted networks only, upgrade FortiOS to 7.2.11, 7.4.8, or 7.6.1 or later, and force every administrator to log in post-upgrade to trigger PBKDF2 re-hashing of stored credentials. If you find indicators of compromise, treat the device as fully compromised and run incident response, not just credential rotation.

Why did fully-patched FortiGate devices still get compromised?

Two reasons. First, CVE-2026-24858 was a second authentication bypass that existed alongside the previously-patched SAML SSO bypass CVEs patched devices were still vulnerable to the second flaw until that patch was applied. Second, even after firmware upgrade, administrator passwords remained stored as legacy SHA-256 hashes until each administrator logged in following the upgrade. Most organisations upgraded the firmware but never re-logged-in administrators, leaving credentials in the faster-to-crack format.

Is rotating my password enough to remove the attacker?

No. The threat group's pattern includes deploying persistent network sniffers on compromised devices, creating backdoor administrator accounts like "support" with unrestricted firewall policies, and pivoting to internal Active Directory. Password rotation does not remove a sniffer, delete a backdoor account, or undo lateral movement. If you have indicators of compromise, full incident response is required, and full device replacement may be more reliable than cleaning a potentially-compromised appliance in place.