FortiBleed dumps 73,932 Fortinet firewall creds; CISA orders resets

Researcher Volodymyr "Bob" Diachenko disclosed on June 17, 2026 that an attacker-controlled server, left open on the internet, held a working credential set for 73,932 unique Fortinet FortiGate firewalls across 194 countries and 21,632 unique domains. Threat-intel firm Hudson Rock named the campaign FortiBleed and validated the dataset; independent researcher Kevin Beaumont spot-checked credentials against live appliances and confirmed they authenticated. CISA issued a hardening advisory the following day ordering customers to terminate sessions and reset passwords. Fortinet's PSIRT posted its own note the same day with hash-cleanup steps for upgraded devices.

This is not a vulnerability. There is no CVE, no zero-day, no patch. It is a credential-reuse and infostealer-harvest operation conducted at industrial scale.

What the dataset contains

Per Hudson Rock's analysis, recoupé by Diachenko's published artefacts, each record ties a FortiGate management URL to one or more administrator or SSL VPN user credentials in cleartext — no hashing left to crack. Among the organisations named in the dataset: Foxconn, Samsung, Comcast, Siemens, Lenovo, PwC, Accenture, Oracle, plus government entities and critical-infrastructure operators across the 194-country footprint. The 73,932 number represents roughly half of all internet-facing FortiGate appliances tracked by public exposure scanners.

The credentials came from two parallel streams:

• Infostealer logs. Workstations with cached browser-saved FortiGate admin or VPN logins, harvested by RedLine / Lumma / StealC / similar families, sold on credential markets, then aggregated by the FortiBleed operator.
• Credential reuse. Admin passwords leaked in earlier breaches (corporate, personal, or unrelated SaaS) that the same identity reused on its FortiGate.

The campaign operator chained the aggregated lists with high-rate authentication probes against exposed FortiGate IPs. Hudson Rock observed roughly 1.16 billion authentication attempts against 320,777 FortiGate targets in the recovered logs.

Why complex passwords didn't save anyone

Diachenko's writeup highlights this explicitly: a non-trivial share of compromised credentials were strong, randomly-generated strings. They were not guessed — they were lifted from an infostealer log on a workstation where someone had logged into the FortiGate management UI from a browser with autofill on.

If your admin workflow involves typing the FortiGate admin password into a browser on a general-purpose workstation, your password complexity policy is irrelevant to this class of compromise.

What CISA says to do today

CISA's June 18 advisory is direct. Quoted verbatim from the alert text:

Terminate all active SSL VPN and administrative sessions. Reset all Fortinet VPN and administrative passwords, especially on internet-facing systems, and enforce strong password policies.

Fortinet's own PSIRT note adds a wrinkle that matters for anyone who has upgraded a FortiGate from older firmware: the SHA-256 hash of the prior password is retained in a hidden old-password setting for backward compatibility. Resetting the visible password does not clear it. On FortiOS 7.2.x and 7.4.x, Fortinet directs administrators to enable login-lockout-upon-weaker-encryption under system password-policy to fully evict the old hash.

Action checklist

1. Terminate every SSL VPN session and admin session now. Don't wait for the next maintenance window. Force re-authentication globally.
2. Reset every administrator password and every SSL VPN user password on every internet-facing FortiGate. Treat compromise as the default assumption — the dataset is half the internet-facing fleet, and your appliance probably is in the half.
3. On FortiOS 7.2.x / 7.4.x, enable login-lockout-upon-weaker-encryption under system password-policy to flush the legacy SHA-256 hash in old-password. Without this step, the prior credential remains exfiltratable from a configuration backup taken by a super-admin.
4. Audit administrative endpoints. Any workstation that has held a saved browser credential for a FortiGate management UI should be considered an infostealer suspect: pull EDR telemetry, hunt for known stealer indicators, and rebuild rather than scrub if you find any.
5. Move management off the public internet. If /login is reachable from 0.0.0.0/0, it is a permanent recruiting station for the next FortiBleed-shaped operator. Restrict to a management VLAN, jump host, or VPN-fronted ACL.
6. Enforce MFA on SSL VPN. A working password alone should not produce a tunnel.
7. Search VPN session logs back to early 2026 for authentications from residential ranges, hosting providers, or geolocations inconsistent with the user. Cleartext-credential abuse leaves no exploit signature — the only telemetry is the session itself looking wrong.

What this is not

A handful of secondary outlets framed FortiBleed as a Fortinet "vulnerability." It is not. The credentials are valid because customers' machines and prior breaches gave them up. Fortinet has acknowledged the dataset and the post-upgrade old-password hash residue, but has not confirmed a new product flaw.

That distinction matters operationally. Patching closes nothing here. The fix is credential hygiene, MFA, and removing internet exposure of the management plane — work that no firmware release will do for you.

Context

FortiBleed lands in the same category as the 2021 dump of ~500,000 FortiGate VPN credentials harvested via CVE-2018-13379, and the 2023 FortiOS post-exploitation symlink technique that retained access on patched appliances. The common thread across five years is not the bug of the moment — it is that Fortinet's edge boxes are high-value enough, and exposed enough, that any leak of authentication material (whether from a CVE, a symlink trick, or browser autofill) reliably scales to the tens of thousands. The FortiBleed operator did not need a new vulnerability; the installed base of internet-facing FortiGate management UIs was sufficient infrastructure on its own.

If you operate a FortiGate, the question for tomorrow is not whether the next FortiBleed is coming. It is whether the credentials it will collect are already on a workstation in your environment, waiting to be scraped.