FortiBleed: Russian Actors Compromised 86,644 Fortinet Firewalls With Never-Rotated Credentials as CISA Issues Urgent Alert for All FortiGate Users

In mid-June 2026, security researcher Volodymyr Diachenko discovered an operational server containing what appeared to be a complete database of valid Fortinet FortiGate firewall credentials. The finding, which SOCRadar dubbed FortiBleed, was not a random list of stolen passwords: it was the active infrastructure of a Russian-speaking group that had executed 1.16 billion authentication attempts against more than 320,000 Fortinet devices over weeks, verifying each correct credential with automated tools. The result: 86,644 verified credentials, with usernames, email addresses and plaintext passwords, for firewalls and VPN gateways across 194 countries. CISA issued an urgent alert on 19 June with immediate action instructions. The cause of FortiBleed is not a zero-day or a code vulnerability: it is passwords that were never rotated after prior breaches, administrator accounts with default names, and an obsolete hashing mechanism that makes credentials crackable with a GPU cluster.

‍

What is FortiBleed and what do we know about the real scope of the campaign?

Facts documented by SOCRadar, BleepingComputer, SecurityWeek, CISA, Arctic Wolf, Hudson Rock and researcher Kevin Beaumont:

• Scope: 86,644 verified credentials from FortiGate devices across 194 countries. Independent investigations by BleepingComputer and Kevin Beaumont confirm the credentials are real and recent. Beaumont, who verified credentials directly with affected organisations, stated: “The data is legit. It is around 75k devices. Almost all are still online and Fortinet devices.”
• Operation scale: the group executed approximately 1.16 billion credential attempts against more than 320,000 FortiGate devices, and in parallel 2.1 billion brute-force attempts against more than 160,000 Microsoft SQL Server systems. The operation used a 45-GPU cluster managed with Hashtopolis to crack SHA-256 password hashes.
• Attack methodology: the group combined three vectors: systematic internet scanning to identify reachable FortiGate devices; exfiltration of device configuration files (the exact source has not been publicly identified); offline GPU cracking of password hashes and automated verification of each correct credential. Compromised devices are then used as listening posts to intercept additional SSL VPN traffic.
• The self-feeding loop: once a FortiGate is compromised, the group uses it to monitor SSL VPN traffic passing through it and collect additional credentials. Those new credentials are fed back into the scanner to compromise more devices. The system feeds itself.
• Victim profile: the database includes notes on each affected organisation’s sector, revenue and employee count. Organisations identified in the leak include Chevron, Samsung, Foxconn, Comcast, AT&T, Mercedes-Benz, Toyota and Siemens. Hudson Rock confirms the campaign has hit “major government entities and critical infrastructure providers.”
• Huntress confirms 845 client organisations affected: cybersecurity firm Huntress cross-referenced the leak’s IPs against their data corpus and confirmed 845 of their partner organisations specifically impacted.
• Threat actor: CISA and independent researchers attribute the campaign to a Russian-speaking group. Tunnelling tools identified in related activity (Chisel, Neo-reGeorg) indicate sophisticated actors, not low-level opportunists.
• The dataset is not yet on criminal forums: SOCRadar states the specific dataset has not been offered or shared on criminal forums at publication, suggesting the group is using it internally. Dark web monitoring is active to detect any distribution.

‍

Why FortiBleed is different: it is not a zero-day, it is the consequence of not rotating credentials

FortiBleed has no CVE. No patch resolves it. It is the practical manifestation of a problem that has existed since perimeter firewalls were connected to the internet: credentials that were compromised in prior breaches, never rotated, now in the hands of a group that used them systematically against the very devices protecting the network. Four technical factors explain why 86,644 devices were exposed:

1. Passwords never rotated after prior breaches. According to SOCRadar, 64.3% of compromised credentials correspond to generic administrative accounts (35%) and built-in Fortinet system accounts (28.3%) that were never renamed or rotated from factory defaults. The attacker’s password list is not random: it is a curated collection of credentials leaked in previous FortiGate incidents.
2. Obsolete hashing mechanism on non-updated versions. Fortinet introduced PBKDF2-based credential hashing in FortiOS 7.2.11, 7.4.8 and 7.6.1, replacing the legacy SHA-256 mechanism. However, when upgrading from earlier versions, existing passwords remain stored as SHA-256 hashes until the corresponding administrator logs in. Many organisations never forced that login, leaving GPU-crackable credentials in their configurations.
3. Management interfaces exposed directly to the internet. Beaumont notes that most affected devices have their FortiGate management interface exposed directly to the internet, a configuration that should be unnecessary in virtually any corporate environment. Restricting management interface access to trusted internal networks would have eliminated the attack vector for this campaign.
4. Approximately 50% of all internet-facing FortiGate devices are in the database. Based on Shodan data, Beaumont estimates the leak contains credentials for approximately half of all internet-accessible Fortinet firewalls in the world. This makes FortiBleed not an isolated incident but a snapshot of how perimeter security fails in 2026.

‍

CISA’s immediate action instructions for Fortinet users

• Terminate all active SSL VPN and administrative sessions immediately on all internet-facing FortiGate devices.
• Rotate all VPN and administrative passwords, especially on internet-exposed systems, and enforce strong password policies. Treat any password used in the last 12 months as potentially compromised.
• Verify PBKDF2 is used for credential storage. On FortiOS 7.2.11, 7.4.8, 7.6.1 and later, force all administrators to log in at least once so credentials are re-hashed with PBKDF2. Alternatively, reset each administrator’s password manually using a super_admin account.
• Review logs for unauthorised access or lateral movement, including SSL VPN sessions from unknown IPs, unauthorised new administrator accounts, and unplanned firewall configuration changes.
• Enable phishing-resistant MFA on all administrative and remote access accounts.
• Block external access to management interfaces. Restrict web and administrative interface access to trusted internal networks or out-of-band management networks.
• Remove unauthorised accounts and rename or remove any generic administrator account with the default name (“admin”).

‍

Key lessons for Spanish organisations with FortiGate

Fortinet FortiGate is the most widely deployed perimeter firewall in Spanish SMBs, mid-market companies and public infrastructure. The FortiBleed pattern is the same we have documented on the Apolo blog with Palo Alto (CVE-2026-0257, June), Check Point (CVE-2026-50751, June) and Cisco SD-WAN (CVE-2026-20262, June): perimeter devices are the priority target in 2026. The difference with FortiBleed is that it does not require a zero-day. It only requires that credentials were never rotated:

• Immediate FortiGate credential audit. Review all FortiGate administrative users for accounts with generic names, passwords not changed in the last 6 months, and accounts no longer needed for current operations.
• Force PBKDF2 on all upgradeable FortiOS devices. If FortiOS 7.2.11, 7.4.8, 7.6.1 or later, force all administrators to log in or reset their passwords to ensure PBKDF2 hashing.
• Restrict the management interface. If the FortiGate web or SSH management interface is internet-accessible, restrict it immediately to trusted IPs.
• Check if the organisation is in the leak. Hudson Rock provides a free FortiBleed lookup tool to verify if the organisation’s FortiGate public IP appears in the compromised dataset.
• If in the dataset, treat as a confirmed incident. Rotate credentials, review VPN access logs from 1 June, look for new administrator accounts or unplanned configuration changes, and activate the incident response protocol.

‍

Cybersecurity as a strategic priority

FortiBleed closes the cycle of a lesson that has repeated throughout June on the Apolo blog: corporate perimeter devices are target #1. Palo Alto, Check Point, Cisco SD-WAN and now Fortinet, all compromised in the same month. But FortiBleed has a nuance the previous CVEs do not: it cannot be fixed with a patch. The solution is operational, not technical. Rotate credentials, force PBKDF2, remove generic accounts, restrict the management interface. These are tasks that take hours, not weeks. 86,644 is the number of organisations that, as of June 2026, had not done any of those things on their internet-facing FortiGate devices.

‍

Apolo Cybersecurity: urgent Fortinet infrastructure audit and hardening for FortiBleed

At Apolo Cybersecurity we help organisations with FortiGate respond to FortiBleed: presence verification in the compromised dataset via the FortiBleed lookup tool, administrative account auditing and removal of generic accounts, PBKDF2 forcing on upgraded devices, management interface restriction, review of SSL VPN session logs from 1 June for unauthorised access, and lateral movement risk assessment if the FortiGate was compromised.

If your organisation uses FortiGate and you have no confirmation that administrative credentials have been rotated in the last 6 months and that the management interface is not internet-accessible, today is the time to verify it.

‍