FortiBleed attacks: why patching your FortiGate isn't enough

FortiBleed attacks are still hitting Fortinet FortiGate firewalls and VPN gateways, and in some cases the attackers lock the real administrators out of their own devices. The FBI and the US Secret Service said so in a joint advisory published Tuesday, October 6, 2026, three and a half months after the stolen credentials behind the campaign first leaked. The key point for anyone running a FortiGate: this is not a bug a firmware update closes, so an up-to-date device can still be in someone else's hands.

Key takeaways

• Still active: the FBI and Secret Service advisory says attackers keep scanning exposed FortiGates with previously stolen credentials, and cites SOCRadar's count of more than 86,644 compromised devices in 194 countries.
• Admin lockout: after logging in, attackers create their own admin accounts, and in some cases delete or change the passwords of the original ones.
• Not a new vulnerability: Fortinet says FortiBleed isn't a flaw in its code; the attackers log in with leaked, reused and cracked credentials, so a patch alone doesn't evict anyone. The agencies say recovery needs steps "beyond standard patching and password resets."
• What to do: lock down management access, end every admin and VPN session, reset passwords, require phishing-resistant MFA, check accounts, logs and API keys, and move admin passwords to PBKDF2.
• Ransomware link: the advisory says access sold through FortiBleed has reached affiliates of the INC/Lynx and Payload ransomware groups.

What FortiBleed attacks are doing now

The advisory describes a campaign that never stopped. According to the FBI and the Secret Service, attackers are still scanning internet-facing FortiGate firewalls and SSL VPN gateways, the portals employees use to connect to the office network from outside, and logging in with credentials obtained earlier. Its table of attacker IP addresses covers activity seen between June 18 and July 23, 2026.

Once inside, they set up their own way back. The agencies say intruders create new administrative accounts that weren't on the device before, with names such as fortiAdmin, forticloud-sync, support_fortinet and itadmin, and that they may have used SSH where that port was open. In some incidents they then delete the existing accounts or change their passwords, which leaves the organization unable to log in to its own firewall while the attackers move further into the network.

That last step is why this matters beyond the firewall. The advisory says the people running FortiBleed act as an initial access broker, a group that breaks in and sells the access, and that buyers so far include affiliates of the INC/Lynx and Payload ransomware operations. The Record reports that a SOCRadar study in July counted at least 12 organizations breached and encrypted with ransomware.

What FortiBleed is and where the credentials came from

FortiBleed became public in June 2026, when the attackers exposed their own backend server. BleepingComputer reported on June 18 that researcher Bob Diachenko found it holding Fortinet VPN usernames, email addresses and plaintext passwords, and that Hudson Rock counted 73,932 unique firewall URLs across 194 countries. CISA's alert, published the same day, put the number at about 74,000 devices. The later figure of 86,644 comes from SOCRadar and is the one the FBI now uses.

The server also showed how the operation worked. Per the advisory, the attackers:

1. Scanned the internet for exposed FortiGate SSL VPN portals.
2. Tried usernames and passwords from earlier Fortinet leak dumps and infostealer logs (credential stuffing), plus common passwords across many accounts (password spraying).
3. Pulled FortiOS user databases and session tokens from the devices they reached.
4. Cracked the stolen password hashes offline on a rented GPU cluster running Hashcat and Hashtopolis.
5. Filtered out honeypots, mapped each victim and ranked targets by revenue and network structure.
6. Packaged working VPN configurations and target lists for sale.

Why a patched FortiGate can still be compromised

Fortinet's own analysis, published June 19, is direct about it: FortiBleed "is not a new Fortinet vulnerability." The company believes the attackers reused credentials from earlier incidents and brute-forced devices with weak passwords and no multifactor authentication (MFA). In BleepingComputer's June report, researcher Kevin Beaumont observed that many affected devices ran relatively recent FortiOS versions.

A firmware update fixes code. It does not change a password an attacker already knows, close a VPN session that's already open, or remove an admin account the attacker created. That's the gap the advisory is pointing at.

Password storage is the other half. The advisory says the campaign exploits "legacy SHA-256 password storage," a fast hash that a GPU cluster can crack at scale. Fortinet's technical tip on PBKDF2, a deliberately slow hashing method, explains three catches:

• PBKDF2 arrives in FortiOS 7.2.11, 7.4.8 and 7.6.1. Earlier builds store admin passwords as SHA-256.
• Upgrading doesn't convert old hashes on its own. Each admin's hash switches to PBKDF2 only when that admin logs in successfully, and accounts nobody uses have to be reset by hand.
• Even after conversion, FortiOS keeps the old SHA-256 hash in a hidden old-password field until you turn on login-lockout-upon-weaker-encryption (called login-lockout-upon-downgrade on 7.2 and 7.4).

So a device can be on a current build and still hold the weak hashes the attackers crack.

The FortiGate checklist, step by step

These are the mitigations in the FBI and Secret Service advisory, in the advisory's order. Fortinet's June guidance lists the same core steps.

Step 1: Take admin access off the internet

Restrict who can reach the management interface. The advisory ranks the options: trusted hosts (good), a local-in policy (better), or no internet administration at all (best).

Step 2: End every session and reset every password

Terminate all active administrative and VPN sessions, then reset all Fortinet VPN and admin passwords, especially on internet-facing devices, and enforce a strong password policy. The session step comes first because an open session can keep working after its password changes.

Step 3: Require phishing-resistant MFA

Put phishing-resistant MFA, such as hardware security keys, on all remote access and administrative accounts, and make sure it's enforced on every external gateway and admin interface.

Step 4: Compare the configuration with a known-good copy

Review firewall and VPN users and settings for unauthorized changes, ideally against a saved configuration you trust. Look hard at accounts you don't recognize, including the names the advisory lists. Fortinet adds forticloud, fortiuser, fortinet-support and fortinet-tech-support to watch for.

Step 5: Read the logs

Check firewall, VPN, authentication and domain controller logs for unusual access, unknown accounts, configuration changes and signs of lateral movement. The advisory lists attacker IP addresses to search for, but warns that cloud addresses get reassigned, so confirm a match with other evidence before blocking or acting on it.

Step 6: Move admin passwords to PBKDF2

On FortiOS 7.2.11, 7.4.8, 7.6.1 or later, make sure every admin hash has converted, reset the accounts that haven't, and remove the legacy hashes. Fortinet warns that once the lockout setting is on, downgrading to firmware without PBKDF2 locks administrators out.

Step 7: Audit the REST API keys

API keys let scripts configure, back up and monitor a FortiGate. The advisory says to remove any key you can't account for and refresh the legitimate ones, so a stolen key doesn't become a back door.

If you're already locked out or compromised

A FortiGate admin lockout means the attackers are already in, so the advisory's incident response steps apply: isolate the affected devices, hunt through logs and other evidence to scope the intrusion, report it to the FBI's IC3, your local FBI field office or your local Secret Service field office, and then remove the attackers. Fortinet says to treat a suspect device as compromised, contact its support if the internal network may be involved, and treat any linked Active Directory or LDAP account as compromised too. We'd add one thing: if an attacker deletes your admin accounts, you'll need another way into the device, so know your console or out-of-band recovery path before you need it.

Bottom line

If you run a FortiGate VPN or management interface on the internet, treat FortiBleed attacks as a credentials problem, not a patching one. The current firmware is necessary but doesn't evict anyone. Ending sessions, resetting passwords, enforcing MFA and auditing accounts and API keys are the steps the FBI and the Secret Service ask for. For a Fortinet flaw that a patch does fix, see our coverage of the FortiMail zero-day, and for another attack on infrastructure organizations trust, the ccTLD registry hijack. More from the week in breaches: the ASOS data breach notice.

FAQ

Is FortiBleed a Fortinet vulnerability?

Not according to Fortinet, which calls it a credential-harvesting campaign and "not a new Fortinet vulnerability." The attackers log in with leaked, reused or cracked credentials. That's why updating firmware alone doesn't remove an attacker who already has a working password or an account of their own.

How do I know if my FortiGate was affected?

Look for admin or VPN accounts you didn't create, password resets you didn't make, logins from unexpected places and configuration changes. The FBI advisory lists account names and IP addresses to check, and Fortinet said in June that it would contact customers it identified as potentially compromised.

Does MFA stop FortiBleed?

It removes the main way in, because a stolen password isn't enough without the second factor. The agencies ask specifically for phishing-resistant MFA on all remote access and admin accounts. It doesn't undo an intrusion that already happened, so pair it with the account and log review.

Which FortiOS versions use PBKDF2 for admin passwords?

FortiOS 7.2.11, 7.4.8 and 7.6.1 and later, per Fortinet's technical guidance. Existing passwords convert when each admin next logs in, and the old SHA-256 copies stay in the configuration until you enable the setting that removes them.