FortiBleed: stolen credentials, not a flaw

On October 6, 2026, the FBI and the U.S. Secret Service published joint advisory JCSA-20261006-01 on FortiBleed, a campaign against internet-facing Fortinet FortiGate firewalls and their SSL VPN gateways. What sets it apart: it does not rest on a new flaw but on credentials. And some victims end up locked out of their own equipment.

What the advisories say

FBI and Secret Service (October 6). The advisory describes FortiBleed as "an active, global credential-compromise campaign targeting internet-facing Fortinet FortiGate firewalls and secure socket layer (SSL) virtual private network (VPN) gateways". It cites SOCRadar, which verified "more than 86,644 compromised devices across 194 countries". The campaign "exploits reused or leaked credentials and legacy SHA-256 password storage, enabling threat actors to harvest and crack authentication data at scale".

The advisory lays out the chain: scanning the internet for SSL VPN portals, credential stuffing and password spraying from old leaks and infostealer logs, cracking hashes on a GPU cluster, creating new admin accounts on the firewall, then enumerating Active Directory. Validated access is then sold. The advisory notes that the chain "has been observed as an initial entry point for ransomware affiliates".

Lockouts. The text says attackers create accounts that did not exist and, in some cases, delete existing ones "to block organizations from accessing affected devices". Recovery then requires "remediation steps beyond standard patching and password resets".

The Canadian Centre for Cyber Security. Its FortiBleed alert AL26-014 recommends inventorying every account on Fortinet devices and disabling or removing unneeded or suspicious ones, restricting management interfaces to trusted networks and hosts, terminating all SSL VPN and admin sessions, resetting passwords, enforcing MFA and updating the firmware.

Why it matters

An organisation that applied every Fortinet patch can still be hit. The way in is a password the attacker already knows, from an old leak or an infected workstation. The vulnerability process does not see it: there is nothing to install.

Lockouts also change the response. When the attacker has deleted the original accounts, the team can no longer read logs or change the configuration of the very device it has to clean. An out-of-band recovery access has to exist in advance.

The scale is the third point. The advisory describes stolen credentials sorted and validated by script, with honeypots filtered out and targets ranked by revenue and network structure, then working VPN access sold on. This is an industrial pipeline, not an opportunist, and an exposed admin portal is simply an entry in its queue.

What we think at Sentrix

1. Take administration off the internet. It is the advisory's "best" option, and the only one that removes the surface rather than filtering it.
2. Inventory the accounts on every firewall, against a reference list kept current. An account nobody recognises is an incident, not a curiosity. The continuous exposure (CTEM) module keeps that inventory, device by device.
3. Reset and terminate sessions, then require phishing-resistant MFA on the VPN and on administration.
4. Plan the recovery access before you need it: a local account outside the directory, a physical or out-of-band console, a written procedure.
5. Treat an unknown account as an intrusion, with our incident response service if needed: the advisory links the chain to ransomware affiliates.

For an MSP or an MSSP, the same admin credentials often serve several client firewalls. One shared password, cracked once, opens the whole fleet. One account per technician and per client, with MFA, is the only defensible set-up.

The next step

Today, list the admin accounts of every FortiGate you manage and compare them with the ones you created. Then check that the admin interface cannot be reached from the internet. If you want to run that review with us, contact us.