Earlier this month, researcher Volodymyr “Bob” Diachenko came across something most security people fear to find: an open server exposed to the internet, with a working database of login credentials. Not a handful. Not hundreds of them. Tens of thousands of legitimate usernames and passwords for Fortinet firewalls and VPN gateways were stolen from businesses in 194 countries.
Now the community calls it FortiBleed. And this week the confirmed number of hacked devices is 86,644. CISA issued an emergency advisory. The UK’s National Cyber Security Centre has weighed in. The source of all this chaos isn’t some sexy zero-day vulnerability with its logo and website; it’s far more mundane and far more uncomfortable. What really occurred
What actually happened
The issue isn’t a new vulnerability; Fortinet has made that clear. The attackers, thought to be a Russian-speaking team, didn't find any smart new hole in FortiOS. Instead, they reused credentials linked to two previously known security flaws, and combined them with AI-optimised brute-force assaults targeting devices with weak passwords and no multi-factor authentication.
The scale of the brute-forcing involved is genuinely difficult to picture. Researchers estimate the campaign attempted roughly 1.16 billion credential combinations against more than 320,000 FortiGate devices, alongside billions more brute-force attempts against exposed MSSQL servers. This wasn't a handful of skilled attackers manually typing passwords; it was automated infrastructure running at industrial scale, testing old and reused credentials against every internet-facing Fortinet device it could find.
Once attackers gained access to a device, the pattern got worse. Compromised firewalls were used to harvest even more credentials from the traffic passing through them, feeding a growing database that snowballed into the 86,000-device figure we're seeing now. Security researchers have flagged a number of suspicious rogue accounts created on compromised systems, usernames like "forticloud" and "fortinet-support" designed to look legitimate to anyone glancing through an admin panel.
No zero-day. No novel exploit chain. Just credentials that should have been rotated years ago, sitting on devices with no second layer of defence behind them.
Why a firewall company is the target
There's a particular irony in a firewall and VPN vendor becoming the entry point for a global credential-stealing campaign. But it makes perfect sense once you think about what these devices actually are. Firewalls and VPN gateways sit at the very edge of a network, facing directly out to the internet by design — that's their job. They are, almost by definition, the most exposed piece of infrastructure an organisation owns.
When an attacker compromises a perimeter device like this, they're not just stealing one password. They're gaining a foothold that can be used to move laterally into the internal network — particularly dangerous in environments where the firewall is integrated with Active Directory or LDAP for authentication. A single weak password on a single internet-facing box can become the open door to an entire enterprise network.
This is exactly why perimeter security appliances – firewalls, VPN concentrators, and remote access gateways – remain one of the most consistently targeted categories of infrastructure year after year. They are high-value, internet-facing, and frequently under-monitored compared to servers and endpoints further inside the network.
The part that should worry every organisation, not just Fortinet users
It would be easy to read this as "a Fortinet problem" and move on if you don't run FortiGate hardware. That would be a mistake. FortiBleed is a case study in a much broader and more dangerous pattern: credential reuse combined with absent MFA is one of the most reliable ways to compromise an organisation, and it works regardless of vendor.
Old credentials from a previous, already-patched incident were never rotated. That single oversight, not changing a password after a known security event, is what allowed attackers to walk straight back in months or years later. It's a quiet reminder that patching a vulnerability and rotating the credentials exposed by that vulnerability are two completely different tasks, and skipping the second one leaves the door unlocked even after you've fixed the lock.
There's also a technical detail buried in the coverage that's worth dwelling on. Fortinet only introduced a modern, properly salted password hashing mechanism (PBKDF2) for administrator credentials in relatively recent FortiOS releases, replacing an older, weaker hashing approach. Devices still running on legacy credential storage were carrying a structural weakness that made stolen data significantly more useful to attackers than it should have been.
What CISA is telling organisations to do right now
For anyone running FortiGate appliances or similar perimeter devices, the response guidance from CISA and Fortinet boils down to a short, urgent checklist:
Terminate all active sessions. Kill every active SSL VPN and administrative session immediately, then force a fresh authentication for everyone.
Reset every credential. All VPN and administrative passwords, especially on anything internet-facing, rotated immediately, not just the ones you suspect were involved.
Turn on phishing-resistant MFA. Every remote access point and admin interface. This alone would have stopped the vast majority of this campaign cold, even with a leaked password in hand.
Audit for rogue accounts. Look specifically for unfamiliar usernames designed to blend in, things like generic-looking support or service account names that weren't created by your team.
Pull management interfaces off the public internet. Admin panels should never be reachable directly from the open internet; restrict access to a VPN or internal network only.
The actual lesson here
Every few months there's a headline-grabbing zero-day with a memorable name, a CVE number, and a rush to patch before proof-of-concept exploit code goes public. Those matter, and they deserve the attention they get. But FortiBleed is a useful reminder that the more boring failure mode, old passwords nobody rotated, no MFA on a perimeter device, and weak credential hygiene compounding over years are still doing more damage at scale than most exotic exploits ever will.
Patching a known vulnerability fixes the hole. It does not retroactively protect you from the credentials that were already exposed through that hole before it was patched. Those two things have to be treated as separate jobs, and FortiBleed is the clearest illustration we've had this year of what happens when an organisation only does the first one.
If there's one habit worth building from this incident, it's a simple one: every time you patch a credential-related vulnerability, rotate the credentials too. The patch closes the door. The rotation changes the lock. You need both.