FortiBleed: there is no patch, because there is no vulnerability

The missing piece

Every dossier on this site so far has had a defect at its centre: a CVE, a deserialization, an unvalidated header. FortiBleed has none. There is no bug, no exploit, no patch that closes the matter — and on that point, Fortinet is right. Which is exactly what makes it hard to deal with.

1. 13 June 2026
   The exposed server

   Diachenko goes public with the FortiGate credential database.

2. 16 June 2026
   The analysis

   SOCRadar and Arctic Wolf publish.

3. 18 June 2026
   The alert

   CISA issues a hardening advisory.

4. 22 June 2026
   The reply

   Fortinet responds, pointing to FG-IR-26-060 and FG-IR-25-647.

5. 1 July 2026
   The link

   SOCRadar ties the campaign to INC Ransom and Lynx.

On 13 June 2026, researcher Volodymyr "Bob" Diachenko went public with an attacker server left exposed on the internet: inside it, a growing database of already-validated FortiGate administrator credentials. On 16 June, SOCRadar and Arctic Wolf published their analyses. On 18 June, CISA issued a hardening alert. On 22 June, Fortinet responded formally, pointing to advisories FG-IR-26-060 and FG-IR-25-647.

Devices with confirmed credentials reached 86,644 across 194 countries: roughly half of every Fortinet firewall reachable from the internet.

How a campaign works without an exploit

1. 01
   Scanning

   hunt for FortiGates with management or SSL VPN exposed
2. 02
   Config export

   the backup file carries topology and password hashes
3. 03
   Offline cracking

   legacy salted SHA-256, on GPU clusters rented by the hour
4. 04
   Legitimate login

   no exploit: authentication succeeds because it is supposed to
5. 05
   Listening post

   the firewall is configured to capture authentication traffic

The chain is mundane, and the mundanity is the point. The attacker scans the internet for FortiGates with a management interface or SSL VPN endpoint exposed. From those, they pull the configuration file — a file designed for backup and migration, which carries the network topology and the password hashes of administrators and local users. Then they crack the hashes offline, on GPU clusters rented by the hour.

The target is legacy salted SHA-256 hashes, fast to test. Fortinet moved to PBKDF2 in builds 7.2.11, 7.4.8 and 7.6.1, with a condition worth reading twice: the upgrade does not rewrite existing hashes. Every administrator stays on SHA-256 until their first login after the upgrade. And it gets worse: for backward compatibility those builds retain the original hash in a hidden old-password field — invisible from the console, perfectly readable in any configuration backup. A device you believe is protected by PBKDF2 can still hand over crackable material.

At that point the attacker logs in. No shellcode, no file on disk, nothing to intercept at the perimeter: the credentials are correct, and authentication succeeds because it is supposed to.

The loop

This is where the campaign stops being credential theft and becomes a machine. Once administrative access is obtained, the attacker configures the firewall as a passive listening post. Arctic Wolf reverse-engineered the toolchain: a "FortiGate Sniffer" panel driving the capture, and a Go binary called CyberStrike Harvester v1.5 that digests pcap and FortiGate text, pulling credentials out of NTLM, Kerberos, RADIUS, TACACS+, LDAP, HTTP, FTP, MSSQL, cookies and session tokens — pre-formatted for Hashcat.

The firewall is not broken into: it is used for what it already does. It sits at the boundary, all authentication traffic passes in front of it by definition, and the FortiOS command to capture that traffic is in the manual.

The harvested credentials re-enter the scanning infrastructure and produce the next target. Arctic Wolf calls it a credential feedback loop: every victim is both target and recruiter. Between 31 May and 15 June: 659 harvesting pipelines, more than 110 million credentials.

Where the access ends up

For two weeks the open question was: an access broker sells — but to whom?

On 1 July SOCRadar answered, by the oldest route available: an OPSEC mistake by the attackers. A server left reachable exposed internal files, logs and operational documentation. Inside, an operator was found logged into the negotiation panels of both INC Ransom and Lynx, actively working ransom demands. A second, independent data point: FortiBleed's victims overlap with those in an INC-linked open directory.

The same documents reveal an organisation of roughly 20 people with a division of labour: a small core running the high-impact intrusions, specialists, and a junior back office. The post-access phase: scanning of ~11,250 FortiGate portals across 150+ countries, admin access confirmed on 409 targets, the full chain — VPN, domain controller, domain admin — on 354, and at least 12 ransomware deployments with hundreds of endpoints encrypted.

What we don't know

A lot.

• The numbers disagree because they don't measure the same thing: ~74,000 devices (CISA, 18 June), 86,644 (19 June), 430,000+ targeted, 110 million credentials, 30,000–75,000 verified per Arctic Wolf. Different validation stages, different dates.
• Attribution is an assessment, not a fact. "Russian-speaking" derives from indirect infrastructure indicators. No agency has formally confirmed it.
• The INC and Lynx link rests on a single vendor, which is withholding aliases, tooling and IOCs pending its whitepaper. Strong evidence, not yet replicated by third parties.
• Fortinet does not share the framing: it describes credential reuse from prior incidents plus brute force against devices lacking password hygiene and MFA, and states the activity is "not related to any recent incident or advisory."
• On AI, vendors contradict each other. Some reports describe AI-assisted tooling; Arctic Wolf examined the recovered material and writes that automation is extensive but does not prove AI-based decision-making: the "CyberStrike" branding uses "AI pentest" language, and that is all that can be claimed.

The ATT&CK IDs at the head of this dossier are copied from the mapping published by Arctic Wolf Labs, not inferred.

What to do

Without waiting for an update that does not exist: remove the management interface and SSL VPN from direct internet exposure — the highest-impact mitigation; rotate all admin, local user and VPN credentials, treating them as already compromised; enforce phishing-resistant MFA (FIDO2 or certificates) on every administrative and remote access path.

Then the part almost everyone gets wrong: upgrade to 7.2.11 / 7.4.8 / 7.6.1, make every administrator perform a post-upgrade login, and on 7.2.x and 7.4.x enable login-lockout-upon-weaker-encryption to purge the leftover SHA-256 material. The upgrade alone is not enough.

For retrospective hunting, the best indicator is documented: configuration file exports to an external IP in the FortiGate audit log. Then admin logins from unusual geographies, new accounts outside the provisioning workflow, changes to logging configuration.

The patch window is bounded; the credential window is not. A CVE gives you a scope and a date. A database of valid credentials stays open until you rotate them yourself, one by one — and it survives any update.