# There's No Patch for FortiBleed. Public-Sector Networks Are Where That Hurts Most.

Every incident I've ever run started with the same reflex. A CVE drops, you check whether you're affected, you find the fixed version, you schedule the window, you patch, you verify, you close the ticket. The entire muscle that public-sector security teams have built over the last decade is wired to that loop. CISA publishes a Known Exploited Vulnerabilities entry, it comes with a due date, the federal agencies move, the state and local shops that pay attention move a beat later, and the work has a clean beginning and a clean end.

FortiBleed breaks that loop on the first step. There is no CVE to look up and no version you can upgrade to that makes it go away, because what's exposed isn't a flaw in the code -- it's your credentials. Firmware still matters here, and I'll get to why, but firmware is the floor, not the fix. The patch reflex isn't wrong; it just stops exactly where this campaign begins. And that is not a footnote to the story. It is the story.

Here is what happened, mechanically, because the shape of it is exactly why there's no patch. Public reporting doesn't describe one clean exploit chain, and that matters -- a single clean chain would imply a single fixable flaw. What it describes is a blended credential campaign. Sometime in the first half of 2026, a threat actor stood up automation that scans the internet for FortiGate firewalls and SSL VPN gateways, then works whatever initial access it can get: credentials reused from earlier Fortinet-related breach dumps and infostealer logs, brute force against devices with weak password hygiene and no MFA, and exposed management surfaces. One documented path in that mix is the device configuration file -- the backup file that, alongside your full network topology, carries the hashed passwords for your administrator and local accounts. Where the actor can obtain that file, it takes the hashes to offline cracking infrastructure, reportedly renting GPU horsepower by the hour, and recovers working passwords. The thing all of these paths have in common is that none of them is an exploit in the way we usually mean. There's no shellcode, no dropped file an EDR agent could flag. At the end of every path is the same event: a valid login. The attacker authenticates the way you do, because the credentials are correct.

And then it does the thing that turns this from a leak into a campaign. Once it owns the firewall, it reconfigures the device into a passive listening post that captures credentials out of the VPN traffic of your own legitimate users as they connect. Those harvested credentials get fed back into the scanner, which uses them to reach the next target. The operation grows itself. A security researcher, Volodymyr Diachenko, found the attacker's own server sitting exposed on the internet around June 13, complete with the tooling and a validated database of credentials, and that's how any of us know the scale at all.

The scale is the part that makes this a government story rather than just another Fortinet bad week. CISA puts the exposure at roughly 74,000 Fortinet devices. The researchers who recovered the server and named the campaign -- SOCRadar, working off the attacker's own files, with credentials independently verified by Kevin Beaumont in collaboration with Hudson Rock -- count 86,644 verified working credentials across 194 countries, and by their Shodan-based estimate that's something like half of every internet-facing Fortinet firewall on the planet. I'm not going to pretend those numbers are the same number; they're different cuts of a moving target, and you should cite whichever one you can defend. What isn't in dispute is the category. CISA's June 18 alert states plainly that actors targeted internet-accessible Fortinet devices "across government and private sector organizations," and the threat-intel reporting around it places telecom among the hardest-hit sectors, with government and education well represented among the affected categories.

That exposure is not an accident, and if you've ever maintained a firewall for a county, a city, a special district, or any of the agencies that sit one acquisition cycle behind the budget they actually need, you already know why.

Fortinet is woven deep into the public-sector perimeter. That's not a knock on the gear -- it's a procurement reality. Fortinet is GovRAMP authorized for state and local agencies, it runs a dedicated federal subsidiary, it sells through the cooperative purchasing contracts that let a strapped IT department skip a full RFP, and it markets directly into the public-safety niche with product lines built around Next Generation 911 and first-responder networks. Fortinet's own materials warn that emergency-response networks are increasingly targeted. They're right. The result is that when a campaign harvests credentials from internet-facing FortiGates, it is harvesting from a population that includes a high-consequence slice of government, education, public safety, and critical infrastructure -- much of it under-resourced, and a lot of it running the networks other people's safety depends on.

Now layer the campaign's selection criteria on top of that population. FortiBleed doesn't need a clever exploit because it's counting on hygiene gaps, and it's counting correctly. SOCRadar's breakdown of the compromised credentials found that generic admin accounts and built-in Fortinet system accounts together make up the majority of the haul. Translate that out of analyst-speak: most victims left the default or generic account names in place, with weak or reused passwords behind them, long before the scanner ever showed up. The attacker had a reliable target list before brute force was even on the table. If you have spent any time inside lean public-sector IT, that finding does not surprise you in the slightest. The firewall got deployed by a vendor or an MSP during a grant-funded modernization push, it works, the person who stood it up moved on or was never on staff to begin with, and "rename the admin account" lives on a hardening checklist that exists in policy and gets applied inconsistently in practice, especially across distributed sites and inherited equipment.

There's a quieter trap underneath that one, and it's the detail I'd want every public-sector admin reading this to chase down today. Late in 2025, Fortinet changed how FortiGate stores administrator credentials, moving from SHA256 to PBKDF2 -- the thing that makes offline cracking expensive enough to matter. That change shipped in FortiOS 7.2.11, 7.4.8, and 7.6.1, and Fortinet is explicit about the catch: when you upgrade from earlier firmware, an existing admin password stays SHA256 until that specific administrator logs in again. So picture the device that got patched -- good, you're current, the ticket is closed -- but the local admin account on it hasn't been used in eight months because everything runs through the central management platform now. That account is patched and still hashed the old, crackable way. It gets worse: Fortinet's own guidance notes the legacy hash can survive in a hidden `old-password` field even after the visible password changes to PBKDF2, and actually purging it means enabling a lockout setting that varies by FortiOS branch. Upgrading does not, by itself, get the crackable hash off the box. You have to log back into every admin account, and on some versions you have to go further than that. Almost nobody does, because almost nobody knows the migration is conditional, and the forgotten account at the small agency is exactly the kind that never gets logged into until an attacker does it for you.

This is the part where the public-safety stakes stop being abstract. A FortiGate is not just a firewall. On a public-sector network it is frequently the VPN concentrator your remote staff connect through, the routing device between segments, a logging source, an identity bridge into Active Directory, and the privileged management plane for the whole edge, all at once. When its admin credentials leak, the blast radius is not the appliance. It's everything the appliance fronts. In a public-safety context that can mean the segment carrying records access, the backhaul that dispatch and field systems ride on, the directory that governs who can authenticate to what. CISA's own remediation guidance tells you to go review your domain controller logs for lateral movement, not just your firewall logs, because the realistic outcome of a cracked FortiGate admin password is an attacker pivoting off the edge and into the directory. The firewall is the front door. The campaign is interested in the house.

And the actor behind it does not look like opportunistic crimeware. The researchers who recovered the server assess the operators as Russian-speaking, with victim selection weighted toward NATO member countries, though they rate those indicators at low confidence and name no actor. They recovered what appeared to be credentials for a defense-industry VPN endpoint among the loot, and reporting around the campaign describes a NATO defense contractor from which classified material was reportedly exfiltrated. Attribution is still open and I'd hold it loosely -- but the operational fingerprints describe an organized, well-resourced operation running a credential marketplace, not a kid with a scanner. For a government or public-safety network, "your perimeter credentials are now a line item in someone's sector-filtered access catalog" is a meaningfully different threat than "you got popped by a botnet."

So who failed here? Not the overworked admin who never renamed `admin`. I want to be precise about that, because the easy version of this article blames the person at the keyboard, and the easy version is wrong. The failure is structural. We have built a public-sector security model that funds the purchase and not the lifecycle. Grant programs and one-time modernization money buy the box. They buy the migration project that stands it up. They do not fund the standing headcount whose entire job is to log back into every admin account every quarter, audit which management interfaces are still reachable from the internet, and confirm the default account names and weak passwords died on day one. Cooperative contracts and GovRAMP authorizations get the appliance in the rack quickly, which is genuinely good, but speed of acquisition has never once implied durability of operation. And the trend is moving the wrong way for the operating side of that equation -- the most recent NASCIO-Deloitte study describes a deteriorating budget picture for state security leaders, with fewer large increases and some outright reductions, which is not the direction the threat curve would justify. The same budget pressure and skills-gap reality that makes Fortinet's "easy to manage, light on staff time" pitch land so well in the public sector is the precise condition FortiBleed monetizes. You cannot buy your way out of a hygiene problem with a procurement vehicle, and we keep trying.

What you can do is treat this like the incident it is rather than the patch it isn't. The remediation guidance from CISA, the UK's NCSC, Singapore's CSA, and Fortinet itself converges, and the order matters more than the list. Terminate every active SSL VPN and administrative session first, because a live attacker session doesn't care that you're about to rotate the password. Then rotate -- reset all Fortinet VPN and administrative credentials, prioritizing anything internet-facing, and assume any credential that touched one of these devices is burned, including the AD or LDAP account if you've integrated directory authentication. Get on fixed firmware, because that's the floor everything else stands on, then confirm your admin credentials are actually stored as PBKDF2 and not the legacy hash -- which means logging back into every account and, on some branches, enabling the lockout setting that purges the old SHA256 hash, not just trusting that the upgrade did it. Enforce phishing-resistant MFA on every external gateway and admin interface, with the understanding that MFA does not retroactively close a config that was exported before you turned it on. Pull the management plane off the public internet entirely -- restrict to trusted hosts, then to a local-in policy, then ideally to out-of-band management with no internet path at all. And hunt: review firewall, VPN, authentication, and domain controller logs for config exports to external IPs, admin logins from geographies you don't operate in, new accounts outside your provisioning workflow, and changes to logging configuration, because a competent attacker turns the logs off on the way through. And if the hunt turns something up -- a rogue admin account, a config change you can't account for, a VPN user nobody provisioned -- credential rotation is no longer enough. NCSC is blunt on this point: at that stage you treat the device as compromised infrastructure, preserve the logs and config as artifacts, isolate it, and rebuild or factory-reset rather than assume a password change evicted whatever persistence the attacker may have left behind.

Run that sequence even if you have no notification from Fortinet, even if your domain isn't in a public lookup tool, and even if your first scan comes back on current firmware. FortiBleed begins with uncertainty instead of a vulnerability record, and the right response to uncertainty is not to wait for a CVE that is never coming. It's to assume the keys are out and change the locks.

The uncomfortable thing about this campaign is that it's not sophisticated in the way we usually mean. It didn't find a clever new flaw. It found a structural one -- the gap between how the public sector buys security and how security actually has to be operated -- and it built an automated machine to harvest that gap at internet scale. The next one will too. The question I keep coming back to isn't how we patch our way out of FortiBleed, because we can't. It's whether we're willing to fund the unglamorous, recurring, never-finished work of operating the perimeter we already paid for, or whether we'll keep treating firewall administration as infrastructure hygiene right up until the moment it becomes incident response.