FortiBleed: why a leaked password was enough to take over a FortiGate

On 6 October 2026 the FBI and the US Secret Service published a joint advisory on FortiBleed, a campaign against internet-facing Fortinet FortiGate firewalls and their VPN gateways (FBI/USSS advisory). The advisory cites SOCRadar’s count of more than 86,644 compromised devices in 194 countries, and describes the campaign as ongoing.

The striking part is what the attackers did not need. Fortinet’s own analysis is blunt: “This is not a new Fortinet vulnerability” (Fortinet PSIRT). No exploit was required. The attackers logged in.

How it worked

The advisory reconstructs the campaign from the attackers’ own server, which they left exposed. In short:

Find the login pages. Automated scans of the internet for FortiGate VPN portals.
Try known passwords. Credential stuffing and password spraying, fed by earlier Fortinet leak dumps and infostealer logs.
Crack the rest. Password hashes taken from compromised devices went to a GPU cluster for offline cracking. Weak legacy SHA-256 storage of administrator passwords made that easier.
Stay in. New administrator accounts were created on the firewall. In some cases the owners’ accounts were deleted or their passwords changed, and victims were locked out of their own devices.
Sell the access. Working VPN configurations and target lists were packaged for other criminals. The advisory notes that FortiBleed has been an entry point for ransomware affiliates.

Every step before “stay in” rests on a single assumption: a valid username and password is enough to log in to the VPN or to the firewall’s administration interface.

What breaks the chain

Take that assumption away and the campaign’s main tools stop working. If the VPN and the admin console also require an approval on the user’s own phone, a sprayed, bought or cracked password is no longer a login. It is a failed attempt, and with a readable approval it is also a signal: someone just used that password, and the person it belongs to sees a request they did not start.

Both the advisory and Fortinet put multi-factor authentication on every administrator and VPN account near the top of their recommendations. That is the part Notakey covers. A FortiGate can send VPN and administrator logins to a RADIUS server, and the Notakey auth-proxy sits in that RADIUS path: it lets your existing RADIUS server check the password, then asks for an approval on the phone, and only answers yes when both succeed. The setup is in our VPN 2FA with RADIUS guide.

What it does not fix

We would rather be precise here than sell you something.

A device that is already compromised. MFA on new logins does nothing about accounts the attackers created, sessions they already hold, or a configuration they changed. The advisory’s own steps come first: terminate all administrative and VPN sessions, reset the passwords, review users and configuration against a known-good copy, and store administrator passwords with PBKDF2 instead of the legacy hashes.
An exposed management interface. The advisory’s first recommendation is to restrict administration from the internet: trusted hosts (good), a local-in policy (better), or no internet administration at all (best). A second factor on an interface that should not be reachable is the weaker fix.
Phishing pages that relay a live login. The advisory asks for phishing-resistant MFA. In the US government’s definition that means FIDO/WebAuthn or PKI, where the key is bound to the real site. A phone approval stops a sprayed or cracked password from being enough, which is what this campaign relied on. It does not, on its own, stop an attacker who proxies a real login through a fake page, as we explain in our post on MFA fatigue and relay attacks. For the handful of accounts that administer the firewall itself, site-bound keys are worth considering.

If you run FortiGate

Three practical points before you put any phone approval in front of a FortiGate. They come from Fortinet’s documentation; we have not lab-tested a FortiGate ourselves, and a FortiGate talks to the auth-proxy over standard RADIUS like any other VPN concentrator.

Raise the RADIUS timeouts. By default FortiGate gives the whole RADIUS exchange 5 seconds (remoteauthtimeout) and resends a request after 5 seconds (timeout on the RADIUS server) (Fortinet: how the two timers work together). That is enough for a password check, not for a person to take out a phone. The auth-proxy holds the request open while the user decides (30 seconds by default), so both values must be comfortably longer than that window. Fortinet’s tip notes that with equal values the FortiGate still sends the request a second time. The auth-proxy recognises a resent request and ignores it, so the user does not get a second approval, but making the resend timeout the longer of the two keeps the exchange to a single request. For example, 60 seconds overall and 90 before a resend (notakey-proxy stands for whatever you named the RADIUS server entry that points at the auth-proxy):
```
config system global
    set remoteauthtimeout 60
end

config user radius
    edit "notakey-proxy"
        set timeout 90
    next
end
```
Administrators can use the same path. FortiGate supports remote authentication for administrators against a RADIUS server (Fortinet: remote authentication for administrators), including a wildcard admin account for everyone in a RADIUS group (Fortinet: configuring wildcard admin accounts). That puts the approval in front of the console the attackers were after, not only in front of the VPN.
Keep one way back in. FortiBleed locked owners out of their own devices. Keep a local emergency administrator with a long unique password, reachable only from trusted hosts, and test it before you need it.

Where to start

Check three things this week: whether your firewall’s administration is reachable from the internet, whether any VPN or admin account still logs in with a password alone, and how administrator passwords are stored. If the second answer is yes, that is the gap FortiBleed was built for.

Try the live demo to approve a login from your own phone in about two minutes, or request a demo and we will map your VPN and firewall logins to a pilot.