On 6 October 2026 the FBI and the United States Secret Service published a joint advisory stating that FortiBleed, a campaign against internet-facing Fortinet firewalls and SSL VPN gateways, is still active. No vulnerability is involved. The credentials it runs on were stolen before the campaign began, which means every control positioned to evaluate a credential was being handed a correct one.
The advisory's own remediation list is the part worth reading twice. For the management plane it offers three options in a stated order of preference, and all three are decisions about what the device answers.
What actually happened
| Date | Event |
|---|---|
| February 2026 | Industrial Cyber reports the campaign as active since at least this month. |
| 18 June 2026 | CISA issues an alert, and the UK NCSC issues guidance the same day. |
| June 2026 | SOCRadar publishes its analysis of the credential set. |
| 6 October 2026 | The FBI and the Secret Service state the campaign remains active and link the access to ransomware deployments. |
The scale is reported two ways. The FBI and Secret Service advisory says more than 86,644 compromised devices across 194 countries, while SOCRadar, whose research uncovered the operation, and SecurityWeek both describe the same 86,644 as verified working credentials rather than devices. No source gives a count of affected organizations.
The sequence SOCRadar describes contains no exploit. Credentials from earlier Fortinet breach dumps and infostealer logs were tested automatically against devices that answered. Inside a device that accepted one, a Go tool SOCRadar calls FortigateSniffer intercepted authentication traffic passively and collected further credentials and password hashes, which went to a GPU cracking cluster and then back into the scanners.
The FBI and the Secret Service describe actors deleting or changing the passwords on original administrator accounts while creating new ones, so the legitimate administrator loses the device and the intruder keeps it. The October advisory also names INC/Lynx and Payload ransomware, a shift from June, when the same campaign was described as credential exposure rather than a ransomware operation.
The gap: the credential was correct
Nothing here failed in the way controls usually fail. Each was asked the question it was built to answer, and answered correctly.
- Credential validation worked. It compares what arrives against what is stored, and what arrived matched, because it had been taken from somewhere else first.
- MFA is the right control and the advisory asks for it. It engages once a credential has been presented to a service that has already answered. Where it was present, it raised the cost of an attempt that still got to be made.
- Patching has nothing to do. There is no CVE here, so the control most organizations reach for on reading an advisory is not in play at all.
What would have had to be true
The advisory ranks the management-plane fixes explicitly: restrict external management via trusted hosts, which it marks good, a local-in policy, better, or remove internet administration altogether, best. Three rungs, one subject, and not one of them touches a credential.
That ranking is not agreement with anybody. What trusted hosts prescribes is a static list of addresses kept by hand, forever, against administrators who move between an office, a home connection and a hotel. The failure mode is lopsided: an address left in too long is silent, a missing one is a call at three in the morning from the person who cannot reach the firewall. So the ranges widen until they are no longer a control, which is why the advisory ranks removing the interface above maintaining the list.
For a management console, that top rung ends the argument. An organization that reaches its consoles only from inside has no stranger left to decide about.
The SSL VPN gateway is where the ladder runs out. A remote access gateway exists to be reached from the internet by people who are not on the network yet, so there is no version of it that stops answering the internet and still works. The top two rungs are unavailable, and the advisory's guidance for remote access is phishing-resistant MFA on every account: correct, necessary, and engaging only after a credential has reached a gateway that already replied.
For a console, the best advice is to stop answering the internet. A remote access gateway cannot take that advice, which leaves it on the one rung nobody has been able to maintain by hand.
Where Veribound would have fitted
Veribound is an intelligence layer. The FortiGate stays, the gateway stays, MFA, the password resets and the credential-storage changes all stay, and the organization's own equipment keeps enforcing its own policy, unchanged.
An agent on each administrator and remote staff device keeps confirming it is still the one the organization trusted. What reaches the organization's existing firewall policy is a trusted origin: the network that device is connecting from, in practice its public address. Those arrive as address-group updates against policy the organization already has, which is the trusted-hosts rung the advisory marks good and nobody has kept current.
Applied here:
- The scanner finds no gateway to test, so a stolen credential arriving from an unrelated network has nowhere to be presented.
- The credentials stay stolen and stay valid, and the resets the advisory asks for are still required.
- MFA still belongs on every account, and stops being the first thing an attacker meets.
What this would not have done. It does not recover a credential already taken by an infostealer or sitting in an old breach dump, which is where the campaign got its raw material. It does nothing inside a device already compromised, because FortigateSniffer harvests authentication traffic arriving legitimately from people the organization trusts. It does not restore a locked-out administrator or undo access already sold on, and it would not have separated an attacker from the staff working alongside them on a network where a trusted device was already connecting.
The honest boundary is population. A console answers a handful of administrators, the easy case, and the case where the advisory's best option already makes anything further unnecessary. A gateway answers everybody who works remotely, a larger group to admit and the harder half of the same device.
Four months after national agencies told organizations to reset and restrict, the campaign is still finding devices. Resets expire the credentials it holds. They do not change who gets to try the next one.
Source: FortiBleed Operations Continue Targeting Exposed Systems Leading to Reports of Lockouts, FBI and U.S. Secret Service, 6 October 2026.
Source: FortiBleed is still active, with attackers locking admins out of Fortinet firewalls, Help Net Security, 7 October 2026.