FortiBleed Has No Patch. The Fix Is a Password, and an MSP Holds Hundreds of Them.

01 Four counts, and who made each one

You will see four different numbers quoted for FortiBleed. They do not contradict each other. Each one measures something different, on a different date.

Hudson Rock also estimated the effort behind it: about 1.16 billion login attempts against more than 320,000 FortiGate targets [ Infosecurity ] . That is the shape of the campaign. Attackers tried a very large number of doors, and on those figures about one target in four ended up with a working password in their dataset.

02 Why there is nothing to patch

Three routes fed the same database. Fortinet names two of them: passwords reused from earlier Fortinet incidents, and brute force [ Fortinet PSIRT ] . Arctic Wolf adds the third. Attackers pulled configuration files off exposed devices and cracked the admin password hashes inside them offline [ Arctic Wolf ] .

The third route is where an upgrade still helps. Fortinet moved admin passwords to PBKDF2 hashing in FortiOS 7.2.11, 7.4.8 and 7.6.1. A device upgraded from an older version keeps the weaker SHA-256 hash for each administrator until that person logs in again, and a hidden “old-password” field can keep the old hash in a configuration backup [ Arctic Wolf ] . Plenty of firewalls run current software and still carry a hash a laptop can crack.

The accounts themselves made the job easier. The Cloud Security Alliance counted about 63% of compromised accounts as default system accounts or generic admin accounts that nobody renamed [ CSA ] . An attacker who knows the username has already done half the work.

03 One password, every client

An MSP is the place this campaign does the most damage per password. You run firewalls for twenty, fifty or two hundred clients. Your engineers need to get into all of them at three in the morning. So a break-glass admin account with the same name, and often the same password, ends up on every device. Attackers who crack it on one client’s firewall can try it on all the others in an afternoon.

The NCSC spells out that risk in its own advice. After a compromise, it tells you to investigate every other edge device that shares credentials with the affected one [ NCSC ] . The CSA goes further and tells MSPs to notify affected clients and document the rotation and MFA rollout [ CSA ] . Your clients will ask for that record.

When we test an MSP’s own estate, a shared admin credential across client devices is one of the findings we raise most often. It usually sits in a password vault that only a few engineers can open. The vault is fine. The problem is that one entry opens forty firewalls.

Cyber Essentials already covers most of this. For every firewall, the requirements say to change default admin passwords to strong, unique ones and to keep the administrative interface off the internet, unless there is a documented business need and it is protected by multi-factor authentication or an IP allow list with properly managed passwords. MFA is expected on admin accounts and on any account reachable from the internet [ Cyber Essentials v3.2 ] . A certificate on the wall says that was true on the day of the assessment. FortiBleed tests whether it is still true today.

The Danish CPR breach last week came down to the same thing at smaller scale: a supplier login, a weak password and no second factor. We wrote that one up in Denmark lost 8.8 million records to the password 123456. FortiBleed is that story repeated across tens of thousands of firewalls.

04 What to do this week

The NCSC and Fortinet agree on the order. Check first, then decide whether you are cleaning up a device or rebuilding one [ NCSC ] [ Fortinet PSIRT ] .

1. Check your domains in the SOCRadar and Hudson Rock FortiBleed checkers, and confirm any device they list really belongs to you or a client.
2. Look for accounts nobody created. Fortinet lists forticloud, fortiuser, fortinet-support and fortinet-tech-support. Check for new VPN users, unexpected password resets and admin logins from unknown IP addresses.
3. If you find one, stop treating it as a password problem. Isolate the device, preserve logs and configuration, then factory reset. The NCSC warns that changing credentials alone may leave the attacker’s persistence in place.
4. Treat the directory account as exposed too. If the FortiGate binds to Active Directory or LDAP, assume that account is compromised and watch for it elsewhere.
5. Close the door the campaign used. Kill all admin and VPN sessions. Set a unique admin password per device. Put multi-factor authentication on every VPN and management login. Take the management interface off the internet.
6. Get onto PBKDF2. Upgrade, then make every administrator log in again or reset their password. On 7.2 and 7.4 Arctic Wolf recommends enabling login-lockout-upon-weaker-encryption to purge the old hashes.
7. Report it. The NCSC asks UK victims to report the incident and to consider an assured Cyber Incident Response provider.

Nothing on that list needs a vendor patch or a new product. It needs someone to log in to every firewall you are responsible for and check. Can you say today which of yours still accept a password on its own from the internet? We can tell you in 14 days, from the outside, the way the FortiBleed crews found theirs. Book a free audit and get the list, device by device.