Discovery & Timeline
Diachenko first raised the alarm on LinkedIn the weekend of June 13-14, 2026, after finding an attacker-controlled server containing a list of working FortiGate passwords. Hudson Rock and SOCRadar independently obtained and analyzed the full dataset; broad public disclosure followed June 17 (BleepingComputer, TechCrunch), with expanding technical analysis, victim attribution, and an official Fortinet statement continuing through June 18.
Scale
73,932 unique Fortinet FortiGate firewall/VPN URLs across 194 countries, touching 21,632 unique domains. Hudson Rock and Beaumont estimate ~75,000 distinct affected devices — approximately half of all internet-facing FortiGate firewalls indexed by Shodan at time of disclosure. SOCRadar independently verified more than 30,791 working administrative credentials within the dataset.
Attack Mechanism — Why This Is Category C, Not a Vulnerability
Attackers harvested FortiGate configuration files from internet-exposed devices and recovered administrator credentials stored within them. The exact method of initial config acquisition is not officially confirmed — researchers say it may stem from a combination of known-but-unpatched Fortinet CVEs, infostealer-harvested credentials, and data from the prior 2025 Belsen Group Fortinet leak. Once obtained, attackers intercepted and cracked SSL VPN authentication hashes offline using a 45-GPU cluster managed through the Hashtopolis cracking platform, then validated the recovered credentials against live, internet-exposed Fortinet management and VPN interfaces at automated, industrial scale: an estimated 1.16 billion credential-based attempts against more than 320,000 FortiGate targets, plus a parallel 2.1 billion brute-force attempts against more than 160,000 internet-exposed Microsoft SQL Server systems.
Why So Many Credentials Were Crackable
Fortinet introduced stronger PBKDF2-based password hashing for administrator credentials in FortiOS 7.2.11, 7.4.8, and 7.6.1, replacing a legacy SHA-256-with-salt method. However, when a device is upgraded from an earlier version, the existing administrator password remains stored as a SHA-256 hash in a hidden "old-password" configuration field — not visible to administrators logged into the firewall, but readable in a configuration backup — until the corresponding administrator next logs in. Many organizations therefore continue to expose crackable legacy hashes even on devices running otherwise current FortiOS versions, unless the "login-lockout-upon-weaker-encryption" setting has been explicitly enabled to purge the old field.
Named Affected Organizations
Per Hudson Rock and multiple corroborating outlets, organizations appearing in the exposed dataset include Oracle, Chevron, Lenovo, FedEx, Foxconn, Samsung, Comcast, AT&T, Mercedes-Benz, Toyota, Siemens, PwC, Accenture, Sinopec, State Grid, and — according to Ars Technica — Fortinet itself, alongside numerous government agencies and critical infrastructure operators. Inclusion in the dataset indicates exposed/valid credentials were found; it does not by itself confirm every named organization suffered a full network breach.
Confirmed Deeper Compromises
Diachenko's investigation reportedly confirmed full network compromises in Japan, Taiwan, Vietnam, Iraq, and Turkey — most notably a Turkish NATO defense contractor from which classified defense documents were allegedly exfiltrated. These deeper-compromise claims have not yet been independently confirmed by Fortinet or third parties in the public reporting reviewed for this update.
Post-Compromise Capability
Researcher Kevin Beaumont notes that working credentials allow attackers to remotely log into the firewall — and by extension the internal network — modify settings including security controls, and create backdoor administrator accounts. Once inside, operators reportedly use compromised firewalls as listening posts, monitoring traversing traffic to harvest additional credentials in a self-reinforcing cycle, and pivoting toward internal Active Directory environments.
Related (Not Root-Cause) Fortinet CVEs Worth Patching Regardless
CVE-2026-24858 — FortiCloud SSO SAML authentication bypass, CVSS up to 9.8, CISA KEV-listed. CVE-2026-35616 — FortiClient EMS improper access control enabling unauthorized code execution, CISA KEV-listed. CVE-2026-21643 — FortiClient EMS SQL injection. CVE-2026-39813 — FortiSandbox JRPC API path traversal/auth bypass, CVSS 9.1 (PSIRT FG-IR-26-112; not yet KEV-listed as of this update). None of these is confirmed as the root cause of FortiBleed, but all warrant immediate patching independent of this campaign.
⚖ Vendor Position — Fortinet Disputes the "New Incident" Framing
Fortinet spokesperson Tiffany Curci told TechCrunch the company is "aware of a reported third-party credential-harvesting campaign targeting Fortinet firewalls and VPN gateways," and characterized the dataset as "a resharing of data from previous incidents, as well as bruteforcing of credentials, and is not related to any recent incident or advisory." Independent researchers counter that the affected IP addresses differ from those in the known 2025 Belsen Group Fortinet leak, and that many sampled devices run recent FortiOS patches — both points cited as evidence this represents a current, distinct credential haul rather than simple recycling of old data. As of this update, the two positions remain unreconciled.
▶ Defensive Actions
1. Use Hudson Rock's free FortiBleed lookup tool to check whether your organization's domains appear in the exposed dataset — but treat a clean result as a starting point, not proof of safety; it cannot rule out exposure the dataset didn't capture.
2. Rotate all FortiGate administrator and SSL VPN credentials immediately, regardless of lookup-tool results, given the scale and automation of this campaign.
3. Enforce MFA on all external-facing Fortinet administrative and VPN access without exception.
4. Restrict FortiGate management interface access to trusted internal IP ranges — researchers note that in the majority of compromised cases, the management interface was directly exposed to the internet.
5. Purge legacy SHA-256 credential hashes by enabling the "login-lockout-upon-weaker-encryption" setting in system password-policy on FortiOS 7.2.x/7.4.x, and confirm administrators have logged in post-upgrade to trigger PBKDF2 re-hashing.
6. Review gateway and VPN logs for anomalous login locations, unexpected administrative sessions, or unusual traffic volume.
7. Audit for backdoor admin accounts and remove dormant or unused accounts entirely.
8. Patch the four related Fortinet CVEs listed above regardless of their unconfirmed connection to this specific campaign.
9. If exposure or compromise is confirmed, investigate for lateral movement into internal Active Directory environments before considering the incident closed.