In June 2026, a security researcher named Volodymyr "Bob" Diachenko found a server sitting open on the internet. Inside was a list. Not stolen files, not malware. A list of working usernames and passwords for the firewalls that sit at the front door of tens of thousands of companies.
By June 19, that list covered roughly 86,644 Fortinet devices across 194 countries. That is about half of all the Fortinet firewalls reachable from the internet. Earlier reporting put the number at 73,932, and it grew as researchers kept counting. The campaign now has a name: FortiBleed.
A firewall is the device that decides who gets in and out of a company's network. Many of them also run a VPN, the encrypted tunnel employees use to log in from home. So these are not minor machines. They are the locks on the main entrance. And someone made a catalog of working keys to a large share of them.
There is no bug to fix
Most security stories you read end with the same advice: a vendor found a flaw, they shipped a patch, install it. Each of those flaws gets a number, a CVE, so everyone can track it.
FortiBleed has no CVE. Fortinet's software was not broken. Nobody forced a door. The keys were simply copied.
Here is how, in plain terms. A group known as SantaAd, advertising on a Russian-speaking crime forum, ran more than a billion login attempts against internet-facing Fortinet devices. They guessed passwords at scale, reused passwords leaked in older breaches, and cracked scrambled password files on a rack of graphics cards built for the job. Then they did the step that matters most: they checked which keys actually worked, and kept only those.
So the result is not a theoretical risk. It is a verified set of logins that open real doors.
Authentication succeeds
Most defenses are built to catch someone forcing their way in. A wrong password, a blocked attempt, a piece of malware that sets off an alarm. FortiBleed produces none of that.
When an attacker logs in with a real password, the system does exactly what it was built to do. It lets them in. The login looks identical to yours. Same kind of username, same kind of session, recorded the same way in the same place. The audit log, the record of who signed in and when, shows a normal, successful sign-in. There is no alarm, because as far as the device can tell, nothing went wrong. The audit log waved them through.
This is the blind spot I write about most. Not "someone broke in." Someone signed in, and the record says yes. A correct password is treated as proof of identity, even when the person typing it is a stranger who bought it at auction.
One key, sold many times
There is a second twist that most of the coverage has skipped, and it is the part that should worry security leaders the most.
SantaAd did not just collect the keys. They sorted them by how much money each victim company makes, and auctioned them off. Higher-revenue companies were offered as premium targets.
That changes the shape of the problem. When access is sold at auction, the same working key can be bought by several different criminal crews at once. A company can have more than one unrelated intruder holding a valid login to the same firewall, at the same time, each one signing in cleanly and looking completely legitimate. The targeting decision was not made by a hacker studying your defenses. It was made by a price list.
Why the usual fixes fall short
The standard reactions to a breach do less than you would hope here.
You cannot patch this, because nothing is broken. Resetting passwords helps, but only if you know which credentials were taken, and only if you reset every one of them everywhere they are used. Miss one, and that login still works. CISA has urged Fortinet customers to rotate credentials and review access, which is the right call, but it is a manual race against a list you cannot fully see.
There is one more catch. A firewall is a sealed appliance. You cannot install antivirus or a monitoring agent on it the way you can on a laptop. So the device that just let an attacker in is also a device with nothing watching it from the inside.
Where you can actually catch it
If the login itself looks normal, and the device cannot watch itself, then the place to catch this is not the moment of sign-in. It is everything that happens after.
A stolen key proves you can open the door. It does not teach the thief how the people who live there behave. The real account signs in from familiar places, at familiar times, and does familiar things. The borrowed one eventually does not. It connects from an unexpected location, at an odd hour, and reaches for systems the real user never touches. That behavior is the part the password cannot fake.
This is the case for watching what a valid account does, not just whether it got in. The sign-in will keep saying yes. What the account does next is where the story gives itself away.
What to do this week
Three practical questions, in plain language:
First, are your Fortinet logins being watched for behavior after sign-in, or only checked for a correct password? Most monitoring is tuned to catch failed logins. FortiBleed produces successful ones.
Second, if a login succeeds from an unfamiliar place, would anyone know? That is the signal that matters here, not a spike in failures.
Third, have you rotated firewall and VPN credentials, and confirmed those same passwords are not reused anywhere else? A copied key is only retired when every copy stops working.
FortiBleed is not really a Fortinet story. It is a reminder that a working login is the one thing a patch cannot close. Detection is not broken. It is incomplete, and the missing half is what happens after authentication succeeds.
---
This is Gap 2 from the Mind Your Attack Gaps framework: authentication succeeds. For the full walkthrough of how valid-credential attacks slip past prevention, see the Gap 2 chapter of the ebook.