Note: This post was written by Claude Opus 4.8. The following is a synthesis of the CISA advisory, Fortinet’s statements, and security-firm research.
On June 18, CISA told organizations running Fortinet firewalls to assume their credentials may be in the wrong hands. The activity — researchers have named it FortiBleed — is the exposure of a large database of working usernames and passwords harvested from internet-facing FortiGate appliances and their SSL VPN gateways. CISA put the scope at “approximately 74,000 Fortinet devices”; security firms tracking the dataset say the count of validated credentials climbed past 86,000 across 194 countries by June 19. If you run FortiGate, the practical question is the one every admin is asking: what actually needs to happen?
What FortiBleed is — and isn’t
Start with what it is not: a single new vulnerability. There is no “FortiBleed CVE” to patch, because the problem is valid credentials, not a software flaw. The leaked data is working SSL VPN and administrative logins; SOCRadar’s breakdown puts it at roughly 35% generic admin accounts, 28% built-in Fortinet system accounts, and 37% organization-specific accounts, and Hudson Rock estimates the exposure touches about half of all internet-facing FortiGates.
How the credentials were collected isn’t fully settled. Fortinet has played it down, saying the data is “likely a resharing of data from previous incidents, as well as brute-forcing of credentials, and not related to any current incident or advisory.” Researchers tracking the campaign describe a Russian-speaking group running on the order of a billion credential attempts against hundreds of thousands of FortiGate targets, blended with infostealer logs and recycled passwords from older breaches. The distinction matters less than it sounds: whether a login leaked last year or last week, a working credential is a working credential, and that is exactly the kind of exposure no patch closes. CISA issued a hardening advisory anyway, which tells you how it reads the risk.
Why patching alone won’t save you
This is the part worth internalizing, because it is the trap. Fortinet moved administrator password storage from salted SHA-256 to PBKDF2 — a far slower-to-crack scheme — in FortiOS 7.2.11, 7.4.8, and 7.6.1. Good. But upgrading does not retroactively re-hash existing passwords. Per Fortinet’s own guidance, an administrator’s password stays stored as the weaker SHA-256 hash until that admin logs in again after the upgrade. In other words, you can be fully “patched” to a current build and still be carrying the easily-cracked hashes the attackers want.
Fortinet exposes a setting to force the issue — login-lockout-upon-weaker-encryption on the 7.2.x and 7.4.x trains — that locks out accounts still on legacy hashing until they re-authenticate, purging the old hashes. CISA’s second instruction is, in effect, to verify this: confirm PBKDF2 is actually in use and “remove weaker legacy hashes.” The lesson generalizes beyond Fortinet — a vendor fix sometimes needs an operational follow-through, and assuming the version number did the work is how a closed hole stays open.
What CISA says to do now
CISA’s advisory is refreshingly concrete. For any FortiGate appliance and its SSL VPN gateway, it urges five steps immediately:
- Terminate sessions and reset credentials. Kill all active SSL VPN and administrative sessions, reset every Fortinet VPN and admin password — especially on internet-facing systems — and enforce a strong password policy. Treat the existing credentials as burned.
- Ensure secure credential storage. Confirm PBKDF2 is storing administrator credentials and remove the legacy SHA-256 hashes, per Fortinet’s technical guidance.
- Review logs. Comb firewall, VPN, authentication, and domain controller logs for lateral movement, unusual access, new accounts, or unauthorized configuration changes. That domain-controller line is the tell: the real damage from a stolen VPN login is the foothold it gives an attacker to move inward toward Active Directory, so checking the firewall alone isn’t enough.
- Enable phishing-resistant MFA. On all remote-access and administrative accounts, enforced on every external gateway and admin interface. A second factor is what makes a leaked password worth far less.
- Reduce the attack surface. Get firewall administration off the public internet entirely, restrict management interfaces to trusted internal networks, and remove unused or unauthorized accounts.
Already restricted access, or enforced MFA?
These are two different controls guarding two different doors, so the protection you have depends on which you’ve done — and many shops have done one, the other, or both. Restricting the management interface takes the administrative login off the internet; enforcing MFA makes a stolen password insufficient by itself.
| What you’ve enforced | What a leaked password still gets into |
|---|---|
| Neither | The SSL VPN and the admin login — both |
| Management lockdown only | The SSL VPN (still internet-facing and password-only) |
| MFA only, on VPN and admin | Nothing on its own — a second factor is required |
| Both | Nothing on its own, and the admin plane isn’t even reachable |
MFA is the control that most directly defeats a credential-replay attack like this one — but it isn’t airtight. MFA that isn’t phishing-resistant can be relayed or fatigue-bombed, and built-in or service accounts (more than a quarter of the leaked set) often don’t sit behind interactive MFA at all. So whichever row you’re in, two things still apply: rotate the exposed credentials anyway — rotation removes the asset entirely and covers the accounts MFA doesn’t — and review the logs, because none of these controls undoes a foothold an attacker established before you turned them on. If you don’t actually use the SSL VPN, disabling it is the strongest single move of all.
Bottom line
FortiBleed is not a clever exploit; it’s a credential-hygiene and exposure story, and the edge VPN is the front door it walks through. The fixes are the unglamorous ones every IT shop already knows it should have done: rotate after any exposure, require MFA, keep the management plane off the internet, and never assume an upgrade scrubbed your stored secrets. Healthcare is among the sectors named in the exposed set, so the safe posture is to treat exposure as the default and work the checklist rather than wait to be told you were hit.
The one genuinely good thing here is that none of it waits on a vendor. There is no patch to chase, because there is no single bug — only valid logins to invalidate, second factors to add, and an internet-facing surface to shrink. Every item on CISA’s list is something an administrator can start today.
Sources
- CISA - CISA Urges Hardening Fortinet Devices After Reports of Credential Exposure
- Fortinet - Technical Tip: Enforcing PBKDF2 as hash function for administrator accounts in FortiOS v7.2.11 and later
- Fortinet - Attacks at the Speed of AI
- Arctic Wolf - Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries
- SOCRadar - FortiBleed: The Compromise of 80,000+ Fortinet Firewalls
- The Hacker News - CISA Warns Fortinet Customers as FortiBleed Credential Leak Widens