Here is the version of FortiBleed you've probably absorbed by osmosis this week: a researcher found a huge pile of stolen Fortinet credentials, half the internet-facing FortiGate fleet is exposed, and — per Fortinet itself — it's not really their fault, because it's not a new vulnerability. It's just bad password hygiene.

That framing is technically accurate. It is also doing an enormous amount of quiet work to make a years-long pattern of Fortinet's own making look like a one-week customer-side accident.

Two things are true at once here, and the public record hasn't fully reconciled them. First: "FortiBleed" isn't one story. It's at least two distinct datasets, discovered weeks apart, that the threat-intel industry has bundled under one catchy name because nobody wants to publish the second-most-exciting headline of the week. Second: the credentials in both datasets didn't materialize from nowhere. They trace back through a documented chain of Fortinet's own disclosed vulnerabilities, a password-hashing upgrade that doesn't actually upgrade your passwords unless you take an extra manual step nobody tells you to expect, and a vendor disclosure history that independent researchers have been quietly criticizing for at least three years. None of that absolves customers who never rotated a default password. But "it's credential reuse, not our problem" is the kind of sentence that's true in the way a company's lawyers need it to be true, not the way an honest postmortem would write it.

Let's take this apart properly.

───────────────────────────────────────────────────

WHAT "FORTIBLEED" ACTUALLY IS — UNTANGLING TWO DATASETS WEARING ONE NAME

Start with the timeline, because the timeline is the tell.

Between June 13 and 17, 2026, security researcher Volodymyr "Bob" Diachenko found an exposed server belonging to the threat actor behind this campaign — sitting open on the public internet, complete with attack tooling, automation scripts, and a structured database of credentials. Threat-intelligence firms Hudson Rock and SOCRadar analyzed the find and gave it a name: FortiBleed. The initial count was roughly 30,000 confirmed devices; within days SOCRadar had revised that up to 73,932, then 86,644 confirmed working credentials spanning 194 countries — researcher Kevin Beaumont independently verified a sample of the logins as real and reasonably current. CISA issued a public alert on June 18, citing the ~74,000 figure, and Fortinet published its own response the next day, attributing the activity to credential reuse from three of its own 2025–2026 FortiCloud SSO authentication-bypass advisories (CVE-2026-24858, CVE-2025-59718, CVE-2025-59719) combined with brute-forcing against devices with no MFA.

That was the story as of June 19. By June 22–23, SOCRadar published a substantially different and much larger picture under the same FortiBleed name: a custom Golang tool it calls FortigateSniffer, which abuses FortiGate's own legitimate diagnostic command (diagnose sniffer packet) to passively capture authentication traffic — not just FortiGate logins, but Kerberos, NTLM, RADIUS, RDP, MSSQL, and a dozen other protocols flowing across compromised devices. This version of the campaign puts the credential count at over 110 million across 80,000+ devices, includes a confirmed June 15 exfiltration of DFS backup data from a NATO-aligned defense contractor, and describes GPU-cracking infrastructure rented from a generative-AI compute provider.

Those are not the same claim. The first dataset is a static, discovered pile of already-stolen logins — a leak. The second is a description of an active, ongoing interception operation running on compromised hardware — a campaign. They may well be connected; SOCRadar is the named source behind both reports and presumably has reasons to treat them as one continuous operation. But no source BCG has found — not SOCRadar's own reporting, not CISA, not Fortinet — has published a single sentence reconciling an 86,644-credential static leak with a 110-million-credential active-sniffing operation under one coherent scope. They simply share a name, a vendor, and a publication window.

This matters beyond pedantry. A static leak and an active sniffer call for different defensive postures, different urgency, and different liability questions, and collapsing them into one brand name (the rhyme with "Heartbleed" is doing a lot of the emotional lifting here) makes the story easier to cover and harder to actually scope. One more wrinkle worth flagging explicitly: SecurityWeek's reporting on the SOCRadar deep-dive notes the FortigateSniffer tool was "likely built with the assistance of" an AI-powered autonomous penetration-testing agent called CyberStrike. That's a single-outlet, hedged ("likely") claim with no independent corroboration BCG can locate. Treat it as a developing signal, not a finding — interesting if true, unverified as written.

───────────────────────────────────────────────────

HOW IT HAPPENED — THREE LAYERS, AND A CONTESTED FOURTH

Set the naming confusion aside for a moment. However many distinct operations are actually running under the FortiBleed banner, the credentials at the bottom of all of them had to come from somewhere. Tracing that supply chain is where this stops being a story about one bad week and starts being a story about a vendor's track record.

Layer one: the original sin. Fortinet's FortiOS and FortiProxy have a long, well-documented history of severe, frequently zero-day-exploited vulnerabilities in exactly the components that matter here — SSL VPN and authentication. CVE-2018-13379, disclosed in 2019, allowed attackers to download SSL-VPN system files and harvest credentials wholesale; it leaked roughly 50,000 devices' worth of access and was still being actively exploited years after disclosure. CVE-2022-40684 (authentication bypass) and CVE-2022-42475 (heap-based buffer overflow) followed in 2022. CVE-2023-27997 — nicknamed "XORtigate" — was a heap-based buffer overflow disclosed in June 2023 that researcher Charles Fol of Lexfo Security publicly flagged as critical via social media before Fortinet's own security bulletin gave IT teams enough technical detail to triage it (more on that in a moment). CVE-2024-21762 (out-of-bounds write in the SSL VPN daemon) landed in February 2024. CVE-2024-55591 — another authentication bypass, this one via a Node.js websocket module — was disclosed in January 2025 after Arctic Wolf had already published evidence of in-the-wild zero-day exploitation; Fortinet's advisory didn't credit Arctic Wolf with the discovery. CISA's own tracking, per BleepingComputer's June 19 reporting, counts 26 distinct Fortinet flaws exploited in the wild "in recent years," 13 of which have been weaponized in ransomware attacks specifically.

Several independent firms — Bitsight, Censys, and the managed-security shops Cyber Unit and Falcon Internet among them — trace the original mass theft of FortiGate configuration files (the artifact from which administrator credential hashes are extracted and later cracked offline) specifically to this 2022–2024 cluster: CVE-2022-40684, CVE-2023-27997, and CVE-2024-55591. That is a different, and notably older, set of root causes than the one Fortinet's own June 19 statement names.

Layer two: the hashing trap. Even where Fortinet did the right thing, it did it in a way that quietly extended the exposure window. FortiOS stored administrator passwords using SHA-256 hashing — fast to compute, and therefore fast to crack at scale on commodity GPUs — until Fortinet introduced the much slower, more resistant PBKDF2 algorithm in FortiOS 7.2.11, 7.4.8, and 7.6.1. Here's the catch, documented in Fortinet's own release notes and flagged independently by Arctic Wolf and Falcon Internet: upgrading the firmware does not automatically rehash existing administrator passwords. The conversion only happens when an administrator interactively logs in after the upgrade. An organization that patched diligently — installed the new firmware on schedule, checked the compliance box — but didn't separately instruct every admin to log back in afterward kept storing passwords in the weaker, GPU-crackable format indefinitely. This is not a customer hygiene failure. It is a specific engineering decision Fortinet made about how to roll out a security improvement, and it is the kind of decision that turns "we shipped the fix months ago" into a sentence that's true on paper and false in practice.

Layer three: customer-side hygiene — but not the kind that needed sophistication to exploit. SOCRadar's breakdown of the original 86,644-credential dataset found that 35% were generic admin accounts and 28.3% were Fortinet's own built-in system accounts — meaning nearly two-thirds of the compromised credentials required no cracking, no brute force, and no skill whatsoever, because they were never renamed or rotated away from their factory state in the first place. As SOCRadar put it, that "points directly to a widespread failure to rename default accounts or rotate factory credentials, giving the attacker a highly reliable target list before any brute force was even needed." This part really is on the customers. It is also the least surprising and least interesting part of the story, and it's the part Fortinet's statement leans on hardest.

Layer four — the contested one: who's actually right about the root cause? Fortinet's June 19 statement names CVE-2026-24858, CVE-2025-59718, and CVE-2025-59719 — three FortiCloud single-sign-on authentication-bypass flaws from late 2025 and early 2026 — as the "prior incidents" whose credentials are now being recycled. Multiple independent research and managed-security firms, working from the same public dataset, instead point further back to the 2022–2024 cluster described above. Both explanations are plausible; both are internally coherent; nobody has published evidence reconciling them, and BCG hasn't found a single source that even acknowledges the discrepancy exists. This is exactly the kind of gap a vendor's own incident statement is structurally incentivized to leave unresolved: naming the most recent, narrowest set of "prior incidents" makes the company's own track record look like a brief and contained problem rather than a multi-year pattern across a much larger set of disclosed flaws. That's an analytical inference on BCG's part, not a confirmed finding — but it's the inference the public record actually supports once you put Fortinet's statement next to the independent research it's standing next to.

───────────────────────────────────────────────────

CONSEQUENCES ON THE GROUND

The headline numbers, kept carefully separated per the scoping problem above: somewhere between 73,932 and 86,644 confirmed, verified-working Fortinet credentials across 194 countries in the original leak — call it roughly half the internet-facing FortiGate fleet, a figure repeated across CISA, SOCRadar, and BleepingComputer's reporting. Separately, and on a different basis of measurement, SOCRadar's later, deeper report describes 110 million credentials harvested via active sniffing across 24 authentication protocols on 80,000+ compromised devices. Treat these as describing overlapping but not identical scopes until someone publishes a reconciliation.

The one confirmed real-world consequence with a name attached, however thin the public detail: a NATO-aligned defense contractor had Distributed File System backup data exfiltrated on June 15, 2026, discovered through the same Kerberos-cracking pipeline SOCRadar attributes to the sniffer tool. No contractor name, sector specificity beyond "defense," or damage assessment has been made public as of this writing.

Below that single confirmed incident, the broader victim profile skews toward exactly the organizations least equipped to respond: SOCRadar's original breakdown found roughly 42% of affected organizations had between 51 and 200 employees — large enough to run enterprise-grade Fortinet hardware, small enough to lack a dedicated security operations center to monitor it. IT services and managed-service providers accounted for 8.4% of victims specifically, which matters disproportionately: an MSP with FortiGate-based access into multiple downstream clients is a single point of compromise that fans out. Geographically, India (11.4%) and the United States (10.1%) carry the heaviest concentrations, though the dataset's spread across 194 countries means this is closer to a background condition of the internet than a targeted regional campaign.

The downstream risk worth watching is tiered, not uniform. Bitsight's threat-intelligence team has observed post-exploitation tooling — Chisel and Neo-reGeorg, both tunneling utilities — deployed in some FortiBleed-linked intrusions that have previously been associated with state-sponsored campaigns targeting Fortinet perimeter devices, including Volt Typhoon. This is an analytical inference, not a confirmed attribution: tool overlap is a weak signal on its own, and Bitsight's own reporting does not claim the FortiBleed credential pool is being used by the same actors who ran Volt Typhoon. What it does suggest is a layered threat landscape — opportunistic, financially motivated actors monetizing the credential pool at one tier, while the same pool is plausibly available to more sophisticated, possibly state-adjacent operators at another. Once a credential database this size starts circulating — and Hudson Rock's free public lookup tool and a Russian cybercrime forum listing observed by Bitsight both indicate it already is — there is no meaningful way to contain who gets to use it next.

───────────────────────────────────────────────────

FORESEEABLE CONSEQUENCES

The structural problem with a credential-based incident, as opposed to a CVE, is that a CVE has a closeable window: a patch ships, a deadline passes, exposure shrinks. A leaked-and-circulating credential database does not expire. It remains valid until every single organization in it individually rotates every single password and enforces MFA — and the data so far suggests that compliance with even that baseline step is uneven at best, given that most of the original dataset was generic or default accounts nobody had touched in the first place. Expect this dataset to keep producing breaches for months, not days, as both the original operators and copycat actors who simply scraped Hudson Rock's or the dark-web forum's published indicators work through it at their own pace.

For the NATO-aligned defense contractor specifically, and for any other defense-sector or critical-infrastructure organization that turns up in either dataset, the regulatory exposure is real and largely outside Fortinet's control: U.S. defense contractors face CMMC and DFARS incident-reporting obligations, and European organizations face NIS2 and, where applicable, DORA notification deadlines that a credential-driven incident with no clean "patch date" makes awkward to satisfy cleanly — there's no discrete event to point to, just an ongoing exposure window that may stretch back months or years depending on when a given organization's credentials were actually first compromised.

Expect the cyber-insurance market to treat this the way it treated prior mass-credential events: as a reason to ask pointed renewal questions about MFA enforcement and management-interface exposure specifically, rather than as a single quantifiable loss event. Arctic Wolf is already marketing its insurance-partner program directly against FortiBleed exposure, which is itself a small data point about how quickly this kind of incident gets metabolized into the insurance underwriting cycle rather than into any kind of vendor accountability mechanism.

───────────────────────────────────────────────────

HEADS GOING TO ROLL?

Based on the public record as of this writing: no. BCG found no evidence of any personnel, leadership, or governance consequence at Fortinet tied specifically to FortiBleed — no executive departure, no board statement, no SEC inquiry referencing the incident. That is not a prediction that nothing will happen; it's a description of what has and hasn't happened so far, six days into CISA's public alert.

It's also entirely consistent with the pattern. Go back through the list in Layer One: XORtigate in 2023, criticized at the time by researchers at Lexfo and Patrowl for a security bulletin published with too little technical detail, too late, for IT teams to triage properly. CVE-2024-55591 in January 2025, where Arctic Wolf had already published evidence of in-the-wild zero-day activity before Fortinet's own advisory — and Fortinet's advisory didn't credit them. None of those incidents produced a public accountability moment either, as far as BCG's research turned up. The pattern across years of severe, repeatedly-exploited vulnerabilities in the same product line, at the same vendor, is not one of escalating consequence. It's one of a company that absorbs the reputational hit, ships a fix, and moves on to the next earnings call.

Speaking of which: it's worth noting, with real care to keep this analytically separate from FortiBleed itself, that Fortinet's most consequential public accountability moment of the past year wasn't about security at all. A securities class action filed in late 2025 (State of Rhode Island Office of the General Treasurer v. Fortinet, N.D. Cal., No. 25-cv-08888) alleges Fortinet executives materially misrepresented the scale and durability of a "record" 650,000-unit FortiGate hardware refresh cycle tied to products reaching end-of-service in 2026 — the disclosure that the refresh was already 40–50% complete, and smaller than represented, knocked 22% off Fortinet's share price in a single day in August 2025. That lawsuit has nothing to do with FortiBleed and nothing in the public record connects the two. But it's a genuinely useful data point about where Fortinet's accountability exposure actually lives: in how honestly it talks to investors about a hardware-replacement cycle, not in how its products perform in the field. Wall Street has a mechanism that punishes Fortinet for misleading shareholders about a refresh cycle's revenue trajectory. Nobody has built an equivalent mechanism that punishes a perimeter-security vendor for a non-auto-rehashing password upgrade that left half its customer base on weak hashes for an unspecified number of months. This is an analytical observation about incentive structure, not a claim that the two are legally or causally related — but the asymmetry is the actual story here, more than any single CVE number.

The honest answer to "heads going to roll" is that the liability framework currently in place doesn't have a mechanism for that to happen. Customers bear the entire cost of remediation — credential rotation across tens of thousands of devices, incident response, regulatory notification, reputational cleanup. Fortinet bears a news cycle it has weathered something close to two dozen times in recent years, according to its own regulator's count. Until that asymmetry changes, "not a new vulnerability, just credential reuse" isn't a deflection so much as an accurate description of a system working exactly as currently designed.

───────────────────────────────────────────────────

SOURCING NOTE

This piece draws on CISA's June 18 alert and June 22 update; Fortinet's June 19 public statement; SOCRadar's initial and follow-on ("Dismantling FortiBleed") reporting; reporting and analysis from SecurityWeek, BleepingComputer, The Hacker News, Bitsight, Censys, Arctic Wolf, Cyber Unit, and Falcon Internet; Kevin Beaumont's independent verification work; Patrowl's 2023 commentary on Fortinet's XORtigate disclosure process; Rapid7's January 2025 ETR coverage of the Belsen Group leak; and public securities-litigation filings related to Fortinet's 2025 firewall refresh cycle disclosures, included for incentive-structure context and explicitly not represented as connected to the FortiBleed incident itself. The 110-million-credential figure and the claim regarding AI-assisted tool development are each sourced to a single outlet and are flagged as such rather than treated as independently confirmed.

Jonathan Brown for Border Cyber Group - Support Independent Cybersecurity Journalism. Please Subscribe or Buy us a Coffee! Thanks.