The FortiBleed campaign has produced working login credentials for around 74,000 Fortinet FortiGate firewalls. The Fortinet VPN breach is significant not just for its scale, but for what it reveals about the assumptions businesses make when they buy a perimeter device and consider the job done. Security researcher Kevin Beaumont noted that many of the compromised devices were running fairly recent firmware. So this was not, primarily, a failure to patch. It was a failure of configuration, architecture, and basic hardening.
Table of Contents
Patching is necessary, not sufficient
The standard advice after any major device vulnerability is to patch quickly. Patching matters. But the FortiBleed Fortinet VPN breach caught organisations that were running current firmware, because the problem was not the firmware itself. It was the way administrator passwords were stored, and it was the decision to leave the management interface reachable from the internet.
Fortinet moved from SHA-256 to PBKDF2 password hashing in FortiOS 7.2.11, 7.4.8, and 7.6.1. That is the right direction. The problem is that upgrading to those versions does not automatically re-hash existing credentials. According to Help Net Security, the old SHA-256 hash persists until the administrator logs in after the upgrade. Many organisations did the update and stopped there. They were running patched firmware and still held crackable credentials.
A 45-GPU cluster, managed through Hashtopolis, cracked those SHA-256 hashes at scale. This kind of infrastructure is not exotic. Organised cybercrime groups have used distributed cracking for years. The barrier to cracking SHA-256 password hashes is not high; it is just rarely discussed in the same breath as patch compliance.
Exposed management interfaces are indefensible
The second structural failure shows up in how many devices had their management interface exposed to the internet. Any IP address on the public internet could reach the admin panel or the SSL VPN portal. A firewall’s admin panel exists for administrators on trusted internal networks. Exposing it publicly creates an attack surface that is trivially easy to scan for and target at scale.
Attackers ran 1.16 billion credential attempts against more than 320,000 FortiGate targets, according to BleepingComputer. That is a brute-force campaign that only works because the endpoints were publicly reachable. Restricting management access to specific internal or management-network IP addresses would have stopped those attempts before they started.
This is not a new recommendation. The NCSC, CISA, and Fortinet itself have all published guidance saying to restrict management interface exposure. But guidance does not close the port. Someone has to act on it.
No MFA meant no speed bump
Multi-factor authentication would not stop an attacker who has extracted and cracked a password hash from a configuration file. But it would stop the next step: actually using that credential to log in. The Fortinet VPN breach worked end-to-end, from credential extraction to active network access, because many FortiGate deployments had no MFA on either the VPN gateway or the management interface. A cracked password was enough.
This is also not new guidance. MFA on remote access and management interfaces has been a baseline recommendation for years. The FortiBleed dataset, sorted by sector and company revenue, suggests the attackers expected to find it missing across a broad population of targets. In this Fortinet VPN breach, they were right across 74,000 devices.
What the NCSC’s response tells us
The NCSC advisory recommends a factory reset, not just a credential change. That is a strong signal. Password resets leave everything else in place: backdoor accounts, configuration changes, scheduled tasks planted for persistence. The agency is acknowledging that organisations should assume the device has been modified, not just accessed.
From a penetration-testing perspective, this is exactly right. When we recover valid credentials for a management interface during an engagement, the first thing we do is create a secondary account. Then we change a logging setting, or add a VPN user that survives a credential rotation. The NCSC’s recommendation reflects the same logic: a credential reset against a modified device is a weak response.
The Fortinet VPN breach is a configuration audit, not just an incident
Organisations that are not in the FortiBleed database should not conclude that this does not apply to them. Similar configuration failures are common across a much wider population of Fortinet deployments. Open management interfaces, legacy password hashes, and absent MFA are not unusual. So a new campaign targeting the same attack surface would find the same conditions.
The right response is to treat FortiBleed as a forcing function for a configuration audit. Check what faces the internet. Verify that post-upgrade re-hashing was completed. Enforce MFA on every administrative and remote-access path. Confirm that management access is restricted to trusted networks. These are not emergency measures. They are the baseline standard, and the FortiBleed campaign exposed how many organisations are operating below it.
Subscribe to our newsletter for a weekly round up of what's happening in the cyber security world
