Your Fortinet password reset won't lock the FortiBleed attacker out

Resetting a password does not end a session. That one fact is why the FortiBleed campaign against Fortinet firewalls got more dangerous this week, and why the advice most of us gave when the leak first surfaced was only half the job. On June 18, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) warned Fortinet customers that attackers are actively using stolen logins against government and private networks, and laid out a fixed order of actions. The order is the message: kill the sessions first, change the passwords second.

FortiBleed is not a software vulnerability you can patch. It is a database of working logins for internet-facing Fortinet firewalls and VPNs, built by spraying leaked and reused passwords at login endpoints and recording every hit. We covered how that collection worked in our earlier breakdown of the leak. What is new is that CISA has now confirmed those credentials are being spent in the wild, and the true size of the operation is on the table.

What changed between the leak and the CISA alert

When the dataset appeared, the headline number was roughly 73,932 firewall credentials spread across 194 countries. By June 19, reporting put the count of compromised Fortinet devices at 86,644. The campaign itself is larger than the haul suggests. Security researcher Volodymyr Diachenko found a live server holding a working credentials database, and several firms have logged the activity separately, among them Arctic Wolf, SOCRadar, Hudson Rock, and Britain's National Cyber Security Centre. A Russian-speaking group ran on the order of 1.16 billion login attempts against more than 320,000 FortiGate targets to assemble the list.

That last figure reframes the story. This was not opportunistic password guessing. It was industrial credential validation, automated to test every leaked pair against every reachable Fortinet endpoint and keep only the ones that worked. When a campaign verifies each credential before banking it, "potential exposure" is the wrong mental model. If your device was reachable and used a credential that ever appeared in an earlier breach, assume it was tested, and assume the result was recorded.

Why a password reset leaves the attacker logged in

Here is the part the early advice missed, ours included. A Fortinet SSL VPN tunnel or an administrative console session is authenticated once, at connect time. After that, the session rides a token, not the password. Change the stored password and the existing session keeps working until it expires or you tear it down. An attacker who logged in yesterday with a valid credential still has that session today, password reset or not.

This is why CISA lists session termination as the first step, ahead of the reset. Telling a Fortinet operator to rotate credentials without telling them to terminate sessions hands the attacker a window: you change the lock while the intruder is already inside the room. Any remediation plan that starts with password rotation and skips active SSL VPN and admin session termination is incomplete, and on a device that has been live in this campaign, incomplete means still compromised.

Weak hashing turned a leaked file into working logins

The no-CVE-to-patch framing is accurate, but it hides a real product weakness. FortiOS versions before 7.2.11 stored administrator passwords using SHA-256 hashing. SHA-256 is fast, which is what you want for integrity checks and exactly what you do not want for passwords, because fast hashing means cheap brute-forcing. Once a hash dump was in hand, recovering the plaintext was a matter of compute, not luck.

CISA's directive now tells customers to switch credential storage to PBKDF2, a deliberately slow, salted algorithm built to make each guess expensive. That is a real configuration change with a real effect on the next leak, and it is the kind of detail that gets lost when a story is filed as just rotate your passwords. If you run FortiGate, the version of FortiOS you are on decides whether your hashes are easy money for the next campaign.

Treat this as incident response, not a hygiene cleanup

The instinct after a credential leak is to schedule a rotation and move on. The scale here argues against that. With 86,644 devices confirmed compromised and over a billion validation attempts run, the safer assumption for any internet-facing FortiGate is that it was probed, and possibly entered, rather than that it slipped through. That moves the work from routine hygiene to incident response: terminate sessions, hunt for what happened during the access window, and look for lateral movement off the firewall into the network behind it.

FortiBleed also fits a pattern this quarter that should change how teams think about their perimeter. The edge appliance keeps being the entry point, because it sits outside endpoint detection, faces the internet by design, and holds the credentials that open everything behind it. We have written about FortiSandbox appliances under active attack, an Ivanti gateway where you patch and then hunt, a Cisco SD-WAN flaw used to take root, and ransomware that lived entirely off edge-device patch backlogs. The device that guards the network is the one attackers want most, and it is usually the one with the least monitoring on it.

What CISA wants done, and the order that matters

CISA's guidance is a sequence, not a menu. Work it top to bottom on every internet-facing Fortinet device:

1. End every live SSL VPN tunnel and administrative session. Do this before anything else, so a reset cannot be outrun by a connection that is already open.
2. Reset every VPN and administrative password, including built-in service accounts like fgtsadmin and fortimanager.
3. Enable phishing-resistant multi-factor authentication on VPN and admin access.
4. Switch credential storage to PBKDF2 hashing and move off FortiOS builds before 7.2.11.
5. Remove unauthorized accounts and restrict management interfaces so they are not reachable from the public internet.
6. Review authentication and configuration logs for unauthorized logins, new accounts, and signs of lateral movement during the exposure window.

FortiBleed is the cleanest argument yet that an internet-facing credential is a perishable asset. The fix is not a single patch on a single Friday. It is killing the sessions you cannot see, fixing the hashing that made the leak cheap, and treating every reachable firewall as a host that has already been tested by someone running a billion guesses.