TL;DR
- what: A Russian-speaking actor codenamed the FortiBleed campaign has breached 86,644 internet-facing FortiGate firewalls and VPN gateways using leaked credentials, brute-force, and credential stuffing.
- impact: Attackers built a verified, working credential database spanning telecom, government, and education across 194 countries, then passively harvest more credentials from traffic to compromise additional devices.
- fix: CISA urges terminating all VPN/admin sessions, resetting passwords, migrating to PBKDF2 hashing (FortiOS 7.2.11, 7.4.8, 7.6.1) to purge legacy SHA-256 hashes, and enforcing phishing-resistant MFA.
- who: Any organization running internet-facing FortiGate appliances, especially those that never rotated factory credentials or upgraded FortiOS without re-logging in to rehash passwords.
CISA on June 19, 2026 warned Fortinet customers of an active campaign that has compromised 86,644 internet-facing FortiGate appliances. Codenamed FortiBleed and attributed to Russian-speaking threat actors, the operation has built a verified database of working logins for firewalls and VPN gateways across 194 countries. This is not a future risk to patch around. It is an existing breach of perimeter devices that already hold valid credentials for some of the largest enterprises on the planet.
The campaign surfaced last week when researcher Volodymyr "Bob" Diachenko found an exposed server holding the credential database alongside the attacker's tooling and automation scripts. Telecom, government, and education are the top three impacted sectors, with the heaviest exposure in India, the United States, Mexico, Colombia, and Thailand.
How the attack sustains itself
FortiBleed runs as a fully automated, two-step loop. First, the actor mass-scans the internet for Fortinet remote login endpoints, then sprays them with a curated list of leaked Fortinet username and password combinations. Second, once inside a device, the attacker passively monitors traffic passing through it to collect additional credentials. Those new credentials feed the next round of compromises. Each credential is verified as valid before it enters the database, so what the actor holds is not a dump of guesses but a confirmed, working target list.
The U.K. NCSC describes FortiBleed as a global campaign against internet-facing Fortinet firewalls and VPN gateways using brute-force, dictionary, and credential-stuffing techniques. The self-sustaining design is what makes it dangerous: every breached device becomes a sensor that grows the credential set, so the campaign expands without the operator manually sourcing new passwords.
The credential breakdown points at hygiene, not just exploits
SOCRadar's analysis of the compromised credentials is the most telling part of this story. Generic admin accounts make up 35 percent and built-in Fortinet system accounts another 28.3 percent, meaning 63.3 percent of breached credentials are default or factory accounts that were never renamed or rotated. That handed the attacker a highly reliable target list before any brute force was even necessary.
The remaining 36.7 percent are organization-specific accounts, and SOCRadar flags this as the more alarming figure. It means the actor is not just harvesting defaults but has compromised accounts the organizations created themselves, likely sourced from prior breaches where passwords were never changed. Credential reuse is doing as much damage here as any technical flaw.
Why legacy hashing made this possible
Investigators suspect the actor exploited older credential hashing and the way FortiGate has historically stored credentials in configuration files. Fortinet introduced PBKDF2-based hashing for administrator credentials in FortiOS 7.2.11, 7.4.8, and 7.6.1, replacing legacy SHA-256 storage. The catch, per Arctic Wolf, is the upgrade behavior: when you upgrade from an earlier version, existing admin passwords stay stored as SHA-256 hashes until that admin successfully logs in after the upgrade. Many organizations that believe they are on a patched build are therefore still storing administrator credentials as SHA-256 with salt, which is far cheaper to crack at scale.
⚠️ Upgrading FortiOS is not enough on its own — PBKDF2 hashing only takes effect for an administrator after that account logs in following the upgrade. Until then the password remains a legacy SHA-256 hash. Force a login for every admin account after upgrading, then verify no legacy hashes remain in the config.
Fortinet's response
A Fortinet spokesperson told The Hacker News that the data is "likely a resharing of data from previous incidents, as well as brute-forcing of credentials, and not related to any current incident or advisory." The vendor urged organizations to follow best practices, including regular credential rotation and MFA. Whether the credentials are recycled or freshly harvested matters less operationally than the fact that they are valid right now against live devices.
What to do this week
CISA's guidance is concrete and assumes you may already be compromised. Treat any internet-facing FortiGate as suspect and work through the following:
- Terminate all active SSL VPN and administrative sessions immediately.
- Reset all Fortinet VPN and administrative passwords, prioritizing internet-facing systems, and enforce a strong password policy.
- Confirm credentials are stored with PBKDF2 (FortiOS 7.2.11, 7.4.8, or 7.6.1) and remove weaker legacy SHA-256 hashes by forcing each admin to re-login.
- Rename or disable default and built-in system accounts rather than leaving factory names in place.
- Review firewall, VPN, authentication, and domain controller logs for unauthorized configuration changes and suspicious logins.
- Enable phishing-resistant MFA on all external gateways and administrative interfaces.
- Reduce the attack surface and lock down management interfaces from the public internet.
Bottom line — FortiBleed is a reminder that perimeter appliances remain a top-tier path to initial access, and that credential hygiene is a control, not an afterthought. Resetting passwords without purging legacy hashes and removing default accounts leaves the door open. Assume compromise, rotate everything, and verify the hashing actually changed.
With 86,644 devices already in the attacker's verified database and the campaign harvesting fresh credentials from live traffic, the window to act closed for many organizations before the advisory landed. The realistic posture is incident response, not prevention: rotate credentials, hunt your logs for the configuration changes that signal a foothold, and close the management plane to the internet.
Originally published on RedEye Threat Intelligence.
