Adversaries are currently ahead in the race because they coordinate well and operate without the constraints that slow down legitimate organizations: internal policies, GRC reviews, approval chains, and security best practices. FortiBleed is the expected result of threat actors’ intense focus on obtaining access to high-value targets by any available means. There is no new exploit to track in this case. There is no CVE that can be added to a dashboard and marked resolved. This is a credential exposure story. It is more fragmented, less visible, and more difficult to remediate than the traditional vulnerability scenarios security teams are accustomed to handling.
This article presents a FortiBleed threat analysis conducted by Cynet experts. It examines the scale of credential exposure, the potential impact on organizations, and the priority actions that can help reduce risks in environments using Fortinet devices.
FortiBleed Summary
In mid-June, researcher Volodymyr “Bob” Diachenko discovered an attacker-controlled server that had been carelessly exposed to the internet by the operators behind it. The server contained scanning scripts, credential-testing tools, logs, and a victim database organized by company, industry, revenue, and country. It also included a dataset of valid usernames and passwords for approximately 73,932 internet-facing Fortinet FortiGate firewalls and SSL VPN gateways across 194 countries. Research from SOCRadar, Hudson Rock, and independent researcher Kevin Beaumont indicates that the dump appears legitimate. The data seems to have been taken from exported device configurations, rather than only from login-page phishing, and most of the affected devices appear to remain online. Analysts estimate that the exposure may involve roughly half of all Fortinet devices discoverable on the internet.
The key point is that FortiBleed is not a new zero-day. No CVE has been assigned to it. Instead, it is a large-scale credential exposure and validation campaign conducted by a multi-operator, Russian-speaking group. The operators searched the internet for exposed Fortinet devices and tested them against billions of credentials leaked in previous breaches. The activity included approximately 1.16 billion login attempts against more than 320,000 FortiGate targets, alongside a separate brute-force campaign involving 2.1 billion attempts against more than 160,000 MSSQL servers. When password reuse did not work, the operators intercepted SSL VPN authentication hashes and cracked them offline using a GPU cluster.
Two technical details are especially important:
- Strong passwords were not enough to prevent compromise. Many of the compromised credentials were highly complex 20-character passwords. Password length and complexity did not help because the credentials already existed in plaintext within infostealer dumps collected from endpoints before encryption could protect them. Once credentials are leaked, password complexity no longer provides meaningful protection.
- The hashing gap is significant. Older FortiOS versions stored administrator passwords as fast SHA-256 hashes. Newer versions, starting with 7.2.11, use PBKDF2. However, after an upgrade, the older weak hash can remain in place until the administrator logs in again or resets the password. As a result, a device that is patched and running a current version can still contain a legacy hash that remains feasible to crack.
This explains why edge devices are such valuable targets. After gaining access to a device, attackers can use it as a monitoring point. They can observe traffic, collect additional credentials, and feed those credentials back into the scanner. From that position, access to Active Directory can follow quickly. At that stage, the incident timeline has already begun.
Who’s impacted
An organization appearing in the dataset does not automatically mean that a confirmed breach occurred. However, the scope of the exposure is broad. Public reporting from Hudson Rock, SOCRadar, and Tech Times lists exposed credentials associated with organizations across nearly every sector of the global economy. Reported names include Accenture, PwC, Oracle, Samsung, Siemens, Foxconn, Lenovo, Comcast, AT&T, Chevron, Mercedes-Benz, and Toyota. The reporting also references an unspecified number of government agencies and critical infrastructure operators.
- Geography: the exposure spans 194 countries, with the largest concentrations of affected devices in India, the United States, Taiwan, and Mexico.
- Most affected industries: IT services, construction materials, and telecommunications.
- The most serious reported consequence is Diachenko’s confirmation of a full-network compromise and the exfiltration of classified documents from a Turkish NATO defense contractor. This is not only opportunistic cybercrime. Bitsight has observed state-associated tunneling tools, including Chisel and Neo-reGeorg, which were previously seen in Volt Typhoon activity, drawing from the same credential pool. In practical terms, criminal groups and well-resourced state-linked actors appear to be using the same supply of compromised credentials.
MSPs and MSSPs face an amplified level of risk. A single compromised administrator account used to manage Fortinet infrastructure for multiple customers can expose many downstream environments at once. In such cases, the incident should be treated as a multi-tenant exposure rather than as cleanup of a single device.
Fortinet’s position is that the data represents a reshare of material from previous incidents combined with brute-forced credentials, and that it is not connected to any recent advisory. That position does not reduce the required response. If a valid credential for a gateway is circulating, the situation requires urgent attention.
Government warnings and advisories
On June 18, 2026, CISA issued an alert that explicitly named FortiBleed and referenced credentials tied to approximately 74,000 Fortinet devices across government and private-sector networks. Notably, CISA recommends reviewing domain controller logs in addition to firewall and VPN logs. In simple terms, the agency does not view this as an issue that stops at the firewall. This is an identity-related incident disguised as a network-appliance problem. Fortinet has also appeared in previous government warnings; the Netherlands previously attributed a separate FortiGate campaign affecting more than 20,000 devices to China.
Although FortiBleed itself has no CVE, several related Fortinet vulnerabilities are being actively exploited and should be patched as a matter of principle. Some are already listed in CISA’s Known Exploited Vulnerabilities catalog:
- CVE-2026-35616 — FortiClient EMS improper access control, listed in CISA KEV
- CVE-2026-24858 — FortiCloud SSO authentication bypass, listed in CISA KEV
- CVE-2026-21643 — FortiClient EMS SQL injection
- CVE-2026-39813 — FortiSandbox JRPC API path traversal, CVSS 9.1
These vulnerabilities are separate from FortiBleed. Patching them should not be treated as a fix for the credential exposure problem, because it is not. They should still be patched.
Recommended defensive actions
The operational timeline is critical. The window between disclosure and exploitation has collapsed from roughly 32 days to less than one day, as attackers increasingly use AI to reverse-engineer and weaponize issues faster than traditional change-management processes were designed to handle. Security teams do not have time to move through the full playbook slowly.
Based on CISA guidance and the consensus among researchers, the following actions should be prioritized:
- Session termination and credential reset. All active SSL VPN and administrative sessions should be terminated. Every Fortinet VPN and administrator password should then be reset, beginning with internet-facing systems. Any credential that may appear in the dataset should be treated as compromised, regardless of its apparent strength.
- Phishing-resistant MFA enforcement. Phishing-resistant MFA should be enforced across every remote-access and administrative interface without exception. This is the control that can neutralize a stolen plaintext credential. Certificate-based or token-based methods should be preferred, while SMS-based MFA should be avoided.
- Credential-storage remediation. Organizations should confirm that PBKDF2 is in use and actively remove lingering legacy SHA-256 hashes in accordance with Fortinet’s FortiOS 7.2.11+ guidance. An upgrade alone should not be assumed to have removed the legacy hash.
- Removal of management interfaces from the public internet. Administrative interfaces should be restricted to trusted internal networks through local-in policies. Dormant or unnecessary accounts should be removed or disabled. Forgotten administrator accounts are precisely where this type of risk often persists.
- Threat hunting rather than simple scanning. Firewall, VPN, authentication, and domain controller logs should be reviewed for signs such as impossible-travel logins, unexpected administrative sessions, newly created accounts, or configuration changes. A malicious login using valid credentials can look like any other successful login. For that reason, it must be actively hunted.
- Exposure checks using public lookup tools. Public lookup tools, such as Hudson Rock’s Fortinet checker and breached.company, can be used as a starting point for exposure assessment. However, the absence of a match should not be treated as confirmation that there is no risk. These tools do not replace log review or credential rotation.
- Patching of related CVEs. The related CVEs listed above should be patched, with priority given to FortiClient EMS, FortiSandbox, and any Fortinet issues included in CISA KEV.
- Assume-breach posture at the VPN boundary. The VPN boundary should be treated as potentially compromised. Password rotation alone does not remove an attacker who has already established persistence inside the environment.
The takeaway
FortiBleed is not a neat security story with a version number and a remediation deadline. It is the more uncomfortable kind of incident: one centered on identity hygiene, edge-device administration, and credentials that were exposed and then forgotten. This is the emerging baseline for critical risk. The firewall stopped being only a perimeter appliance long ago. It now functions as an identity broker and the front door to the domain. It should be defended accordingly.
Panic is not required, but urgency is. Effective response requires clarity, process, and the discipline to match the speed and intensity of the adversaries operating on the other side of the screen.
You can request a demo of Cynet XDR platform to see how it helps detect compromise, automate response, and strengthen the security of your corporate environment. To do so, please leave your contact details in the form below.
