86,644 Working Credentials: FortiBleed Is the Breach Your Patch Cycle Was Never Going to Stop

Four organisations counted the same campaign and produced four different numbers.

Recorded Future put it at 73,932 FortiGate firewall URLs, spread across 194 countries and more than 21,600 domains. eSentire said more than 80,000 Fortinet appliances. SoCRadar said 86,644. Fortinet, in its own statement to SecurityWeek, described a database of over 86,000 confirmed working credentials.

None of them are wrong. They are counting different objects, and the space between those objects is the entire story of FortiBleed.

Unit 42 folded the campaign into its ongoing threat brief on large-scale credential attacks, noting that the activity was publicly reported around August 16 and updating its guidance on August 18. That brief is worth reading in full, but the line that matters most is a small one: Unit 42 says it observed an initial access broker on the Russian-language forum Exploit[.]in claiming responsibility on June 16, referencing a CVE, and offering the harvested credentials for sale. Unit 42 adds, plainly, "we have not validated their claims at this time."

That is an unusually honest sentence for threat intelligence, and it points at something defenders keep getting wrong about this class of attack.

Three counts, three different objects

Here is what each number actually measures.

Recorded Future's 73,932 is a count of distinct FortiGate URLs present in the leaked dataset. It is a count of devices whose configuration ended up in someone's collection.

Fortinet's 86,000-plus is a count of credentials confirmed to work. Credentials, not devices. One firewall can contribute several: a local admin, a handful of SSL VPN users, a service account nobody has logged into since the appliance was racked.

And then there is the number almost nobody quoted. Recorded Future documented approximately 1.16 billion credential attempts against 320,777 FortiGate targets.

Do the division. Roughly 320,000 devices were touched. Roughly 74,000 ended up in the dataset. That is a conversion rate near 23 percent.

I want you to sit with that figure, because it is the most useful thing in this entire disclosure. Nearly one in four internet-facing FortiGate devices that this operation reached gave up something usable. Not one in four thousand. One in four.

If your instinct is that your organisation is in the safe 77 percent, ask yourself how you would know. The evidence for membership in that group is an absence: no alert, no anomaly, no ticket. Absence of evidence is exactly what this campaign produces on the way in.

No zero-day required

The mechanics are almost disappointingly ordinary, and that is the point.

According to Recorded Future's analysis, the operators intercepted SSL VPN authentication hashes and ran them through a 45-GPU cluster managed with Hashtopolis to recover plaintext. The dataset itself, they assess, likely originated from exported FortiGate configuration files. First observed attack activity was June 7, over HTTP on port 9999. The researcher Volodymyr Diachenko went public on June 13.

Fortinet's own read is consistent. Its statement was that the activity "involves threat actors reusing credentials from previous incidents and employing brute-force techniques against devices with weak password hygiene and no multi-factor authentication," and that it "is not related to any recent incident or advisory."

Three FortiCloud SSO authentication bypass flaws sit in the background of the conversation: CVE-2026-24858, patched in January, and CVE-2025-59718 and CVE-2025-59719, both patched in December. Every one of them was fixed months before the dataset surfaced. The IAB's claim to have used a CVE remains, per Unit 42, unvalidated.

So the shape of it is this. Old leaked passwords, sprayed at scale. Configuration files exported. Hashes cracked offline on hardware that costs less than a mid-size SIEM licence. A campaign running since at least February that produced a working key to tens of thousands of network edges without a single novel exploit.

Fortinet's statement is accurate, and that is the uncomfortable part

The reflex in the industry is to read a vendor saying "not related to any recent incident or advisory" as deflection. In this case I think it is simply true, and defenders should be more alarmed by that than by the alternative.

If FortiBleed were a CVE, you would have a workflow for it. You would have a patch window, a change ticket, a compensating control, an executive summary with a green box at the end. The whole apparatus of vulnerability management exists to convert "there is a flaw" into "we did the thing."

FortiBleed does not fit that apparatus, because there is nothing to patch. The credential works. It is supposed to work. It was issued by you, it lives in your config, and the person typing it is authenticating exactly the way the system intends. We covered the same structural problem in our breakdown of the LSHIY ROPC campaign, where 81 million login attempts walked past conditional access using a legacy protocol that was doing precisely what it was designed to do.

The supply side of this is not a mystery either. Our analysis of the 642 million credentials circulating from infostealer logs explains where the spray lists come from, and the Zerofot scanner teardown shows how thoroughly the validation step has been automated. FortiBleed is what happens when that pipeline is pointed at network edge devices instead of cloud APIs.

Rehashing a password that already left the building

Fortinet's remediation guidance includes upgrading to releases that support PBKDF2 hashing of administrator credentials. That is correct advice and you should follow it.

It also does approximately nothing for the organisations already in the dataset.

A stronger hashing algorithm protects a credential that has not yet been stolen. If your configuration file was exported in March and the hash was cracked in April, changing how the appliance stores that value in September is a control applied to the wrong side of the timeline. The plaintext is out. It is in a list. It has been validated against your gateway, and the validation attempt looked like a successful login, because it was one.

This is where the incident response playbook quietly fails. Rotate the admin password, and you have handled the admin password. But a FortiGate configuration export is not one secret. It is a topology document. It names your internal subnets, your VPN pools, your firewall policy structure, your route targets. An attacker who read your config in June knows which internal host to reach for in September even if every password in that file has since been changed. That is a lesson we drew out of the FortiGate service account intrusions earlier this year, and FortiBleed is the same lesson at four orders of magnitude more scale.

What does a FortiBleed login look like in your SIEM?

Let me give you the honest answer from the detection engineering side, because I have built these rules and watched them fail.

It looks like a login.

Unit 42's recommendation is to audit remote access logs for successful logins shortly after large-volume password failure events. That is a genuinely good heuristic and I would deploy it today. But notice its assumption: it requires the spray and the use to be adjacent in time. FortiBleed's operators separated those two phases by months. The spraying and hash interception happened in one window. The offline cracking happened on the GPU cluster. The credential sale was advertised in June. The actual intrusion by whoever buys that list happens whenever they get around to it.

By the time the credential is used in anger, the failure spike it came from has aged out of your hot storage. The correlation window that would have caught it does not exist any more.

Behavioural analytics fare a little better and still struggle here. A VPN authentication from a residential IP in a country where you have staff, during business hours, using a credential that belongs to a real account, producing traffic to internal ranges that account is entitled to reach, is not statistically strange. You can tune a rule to fire on it. You will then tune the rule off again on day three, because your sales team travels.

This is the same wall we hit in the EDR-killer analysis: every detection layer that reasons about whether an action is anomalous can be defeated by an action that genuinely is not anomalous.

The credential nobody should ever type

There is one category of signal that does not degrade with time, does not need a correlation window, and does not care whether the attacker looks like your sales team.

It is a credential that has no legitimate user.

Put a decoy VPN account in the FortiGate configuration. Give it a plausible name, a plausible group membership, a password that hashes like every other password in the file. It exists to be exported. If your config is stolen and cracked, that credential goes into the same list as the real ones, gets validated by the same automation, and gets sold to the same buyer. When somebody authenticates with it, there is no probability to assess. No human being has a reason to use that account. The alert is the event.

That is the practical meaning of zero false positives, and it is not a marketing claim so much as an arithmetic one. A detection with no legitimate trigger path cannot produce a false positive.

The same logic extends inward, which matters more than the edge does. Since the attacker has your topology from the config file, the interesting question is not whether they get in, but what they touch on the way to your domain controllers. Decoy internal services listening on the subnets your config advertises, of the kind MineField deploys, turn the attacker's own reconnaissance advantage into a tripwire. They know your network map. They do not know which entries on it are real.

I will add the caveat that a decoy account only works if it survives housekeeping. The most common way these fail is not the attacker spotting them. It is an internal audit flagging a stale VPN account with no owner and dutifully deleting it. Document the decoys somewhere your auditors read, or you will lose them on a compliance sweep and never know your tripwire was cut.

The number to carry out of this

Twenty-three percent. That is the share of touched FortiGate devices that produced usable material in a campaign that used no zero-day, no novel malware, and no technique invented after 2015.

Patching was never going to move that number, because nothing in the chain was unpatched. MFA moves it a lot, and you should enforce it on every SSL VPN portal you own before you finish this week. But MFA is a control on the front door of a house whose blueprints are already in circulation, and the honest position is that some fraction of those 86,000 credentials will be used successfully against organisations that did everything the advisory told them to.

For that fraction, the only thing standing between an authenticated stranger and your domain admin hashes is whether you planted something in the network that has no reason to be touched. If you want to see what that looks like in a live FortiGate environment before you decide, book a demo with our team and we will walk your topology with you.

Sources: Unit 42, Threat Brief: Mitigating Large-Scale Credential Attacks (updated August 18, 2026); Recorded Future, Critical FortiBleed Campaign; SecurityWeek, Fortinet Responds to FortiBleed Campaign.