A multi-phase campaign has cracked administrative credentials on roughly half of the world’s internet-facing FortiGate firewalls, and because the persistence lies below the operating system, patching will not mitigate all the threats.
The Firewall Is the Foothold Now
The FortiGate sitting at your perimeter is supposed to be the thing standing between the internet and everything you care about, and for roughly half of the internet-facing FortiGates on the planet right now, it is instead the thing the attacker already controls. That is the uncomfortable center of FortiBleed, the campaign disclosed on June 17, 2026, by researcher Bob Diachenko and corroborated by Kevin Beaumont and Hudson Rock, which covers 73,932 FortiGate firewall URLs across 194 countries and 21,632 domains, a number that lines up with about 50 percent of every internet-facing Fortinet firewall visible in Shodan. This is not a single CVE you can look up, score, and close out by Friday. It is an industrialized, self-feeding credential operation that treats your firewall as both the target and the collection sensor, and the more you understand how it works, the clearer it becomes that the muscle memory most teams rely on, patch the box and reboot it, does almost nothing to help here. You must assume you’ve been compromised and perform an integrity scan or re-image the device before bringing it back online.
We got an unusually good look at the machinery because the attackers made a mistake. Their infrastructure was briefly exposed through open directory indexing, which gave researchers a partial view of the toolchain, automated scanning scripts, credential-testing tools, shell histories and cron jobs, the GPU cluster configuration, and the verified-credential database itself. It is structured by organization, sector, revenue, and interface type in exactly the format an initial-access broker uses to sell entry to ransomware crews. Beaumont called that structure a recognizable fingerprint of eCrime syndicates packaging access for sale. He also confirmed that the downstream impact already includes lateral movement into Active Directory across multiple countries and the exfiltration of classified documents from a NATO defense contractor in Turkey.
How FortiBleed Actually Works
The campaign runs in phases, and each phase is interesting less for novelty than for how cleanly the attackers chained things that were already lying around. The reconnaissance phase is the familiar internet-wide sweep for FortiGate SSL VPN endpoints and exposed administrative interfaces. The credential-sourcing phase is where it gets pointed, because the operators drew from two separate pools at once. The first pool was historical and Fortinet-specific, the 2021 leak tied to CVE-2018-13379 that exposed roughly half a million accounts, and the 2022 Belsen Group drop of around fifteen thousand FortiGate configurations that originated from a zero-day. The second pool was infostealer logs, plaintext credentials lifted off endpoint malware, and those matter because they sail straight past password complexity. Hudson Rock confirmed that high-entropy credentials, twenty-five-character random strings that no brute-force effort would ever reach, showed up verbatim because they had been keylogged off an infected workstation rather than guessed.
With pools in hand, the validation phase ran at a scale that is hard to picture, roughly 1.16 billion authentication attempts against more than 320,000 FortiGate targets, with a parallel track of 2.1 billion brute-force attempts against more than 163,000 MSSQL systems, and every successful login written to a verified database tagged with the victim’s industry, revenue, and headcount. For targets that did not fall to a known credential, the operators intercepted SSL VPN authentication hashes and cracked them offline on a 45-GPU Hashtopolis cluster. This is where Fortinet’s own design works against its customers in a way worth dwelling on.
Fortinet migrated administrative credential storage from SHA-256 plus salt to PBKDF2 starting in FortiOS 7.2.11, 7.4.8, and 7.6.1 in early 2025, which is the right direction. The problem is that the migration only triggers when an admin actually logs in after the upgrade, so a device that was dutifully patched but has not had an administrator log in since still stores its hash in the older, far more crackable SHA-256 format. Worse, the old hash does not politely disappear when the migration eventually runs. It persists in a hidden old-password field that does not show up in a normal admin view and is only visible in a full super_admin configuration export. So you can have a fully patched FortiGate reporting a clean version while still carrying a crackable representation of its admin password in a field most operators do not even know exists. Being on a fixed version did not mean the credential was safe.
The phase that should change how you think about these devices is the one that comes after compromise. A compromised FortiGate is turned into a passive network sniffer, quietly harvesting the internal authentication traffic that transits it, VPN user credentials, LDAP and RADIUS bind requests, application logins and service-account calls, and feeding all of it straight back into the credential pool that drives the next round of validation. That is the self-feeding loop, and it is why the dataset keeps growing. To hold the position, the operators install implants and use symlinks to hide files that survive both reboots and firmware upgrades. They create new super-admin accounts, new SSL VPN accounts, and new VPN tunnels so they keep their access even if you rotate the obvious credentials. Arctic Wolf confirmed full network compromises with lateral movement into Active Directory, which is the part of the story where the firewall stops being the prize and becomes the launch point.
The CVE Stack Behind the Campaign
FortiBleed is not powered by a single bug; it is powered by years of them being used together. The dataset and the post-exploitation tradecraft draw on a stack of FortiOS and Fortinet platform vulnerabilities, most of which have public exploits and confirmed in-the-wild use:
| CVE | CVSS | Description | Role in FortiBleed |
|---|---|---|---|
| CVE-2018-13379 | 9.8 | FortiOS SSL-VPN path traversal, plaintext credential exposure | Source of the 2021 leaked credential pool |
| CVE-2022-42475 | 9.3 | FortiOS SSL-VPN heap overflow | Post-exploitation, symlink persistence |
| CVE-2023-27997 | 9.8 | Pre-auth RCE via SSL-VPN stack overflow | Initial access and post-exploitation |
| CVE-2024-21762 | 9.6 | FortiOS SSL-VPN path traversal, in-the-wild zero-day | Root cause of the persistent symlink mechanism |
| CVE-2024-55591 | 9.6 | FortiOS/FortiProxy auth bypass via Node.js websocket | Zero-day in the wild, Belsen Group tie |
| CVE-2025-59718 | 9.8 | FortiCloud SSO SAML auth bypass, admin takeover | Actively exploited as of January 2026 |
| CVE-2026-25815 | 3.2 (exploited) | Default cryptographic key for LDAP creds, the same key on every install | Decrypts LDAP creds straight out of stolen configs |
That last one deserves a callout because the low CVSS score badly undersells it. A single default cryptographic key shared across every installation means that once an attacker has a configuration file, the encrypted LDAP credentials inside it are not really encrypted at all; they are decryptable with a key the attacker already has. A 3.2 that has been exploited in the wild since December 2025 is a perfect example of why scoring a vulnerability in isolation, without the context of a campaign that turns it into free domain credentials, gives you exactly the wrong picture.
Why Patching and Rebooting Will Not Save You
A FortiGate is a closed appliance, which means you cannot run an endpoint agent on it, so your EDR and XDR have no presence on the one device the attacker is living inside. Your vulnerability scanner fingerprints the FortiOS version and checks it against advisories, which works fine for determining whether a patch is available, but that is the wrong question here. The persistence that defines FortiBleed, the implant, the hidden symlink, the rogue super-admin account, the SHA-256 hash sitting in the old-password field, none of it lives in the version string. A device can report itself as fully patched and still carry every artifact of compromise, and the patch you just applied closes the door the attacker walked through without addressing the attacker who is already inside.
This is exactly why the recommendation for these symlink-persistence cases tells you to perform a clean rebuild rather than a patch alone, and why FortiGuard shipped AV and IPS signatures specifically to remove the symlink artifacts left by the SSL-VPN exploitation chain. Patching is necessary, and you should absolutely do it, but if a device was internet-exposed and unpatched during the window this campaign was active, patching is the beginning of your response and not the end of it. The affected builds for the symlink persistence vector are FortiOS 6.4.x before 6.4.16, 7.0.x before 7.0.17, 7.2.x before 7.2.11, 7.4.x before 7.4.7, and 7.6.x before 7.6.2. Upgrading to a fixed build removes the vector for new infections without removing persistence already in place.
The deeper point is that the layer where this campaign operates is a layer most organizations have zero visibility into. There is no agent on your firewall, no telemetry from below the operating system, and no integrity baseline for the firmware, so an implant that survives reboots and firmware upgrades can sit there indefinitely. You cannot remediate what you cannot see, and a version number is not visibility.
What You Actually Need To Do
Treat any FortiGate that was internet-exposed during this campaign as suspect rather than clean, and work the problem at the layer where the compromise actually lives:
- Inventory by exposure, not by version. Identify every Fortinet appliance, then determine which devices have an internet-reachable management interface or an SSL VPN, because those are your real exposure points. Eclypsium helps with this process and supports Fortinet FortiGate devices:
- Check your domain against the Hudson Rock lookup to see if your organization or IP addresses are on the list.
- Hunt for persistence below the OS. Look for symlinks in /data/etc/ and /data/lib/pointing at credential and configuration files, for unexpected packet-capture processes, and for outbound connections from the management plane to anything that is not a known update, NTP, or syslog destination. Verify that the FortiGuard symlink-removal signatures actually ran, rather than assuming the patch handled it. Eclypsium has several threat detections for Fortinet devices:
- Audit credential storage, not just patch level. Export the configuration as super_admin and check for SHA-256 hashes lingering in the old-password field, force admin re-authentication after every upgrade to complete the PBKDF2 migration, and enable login-lockout-upon-weaker-encryption on FortiOS 7.2.x and 7.4.x to purge the legacy hashes.
- Close the CVE-2026-25815 path. Enable private data encryption so your LDAP credentials are not decryptable with the universal default key, and rotate every LDAP and RADIUS bind credential referenced in a FortiGate configuration.
- Rotate downstream, not just local. Any credential that transited a compromised firewall should be considered captured, so rotate the Active Directory and service accounts observable along that path, not only the firewall’s own admin password.
- Rebuild, do not just patch, on any indicator of compromise. Perform a clean install from a trusted image and validate the firmware and configuration, returning them to a known-good state before the device goes back into service.
This is the kind of problem Eclypsium was built for: we look directly at the firmware and low-level components of network devices, compare them against known-good baselines, and surface implants, symlink persistence, configuration weaknesses, and rogue accounts that tools operating at the OS layer and above simply cannot see. FortiBleed is the campaign making headlines this month, but the pattern, an edge device turned into a long-term foothold below the line your security tools can reach, is the one that keeps repeating.
Frequently Asked Questions
No. It is a campaign that chains several known Fortinet vulnerabilities with stolen and cracked credentials. There is no one patch that fixes it.
Not necessarily. Persistence and crackable credentials do not live in the version number. A patched device can still carry an implant, a rogue admin account, or a SHA-256 hash in the hidden old-password field.
Because the PBKDF2 migration only runs when an admin logs in after the upgrade, and the old SHA-256 hash persists in an old-password field, you only see it in a super-admin config export. Until you force that login and purge it, it is still crackable.
No. The symlink persistence is designed to survive reboots and firmware upgrades. Only a clean rebuild from a trusted image removes it.
Check your domain against the Hudson Rock lookup, audit your config for the old-password field and exposed management interfaces, and hunt for symlink persistence below the OS. A version-based scan alone will not tell you.
Stop treating a patched version as a clean device. If a FortiGate was internet-exposed during this campaign, hunt it, rebuild it if compromised, and rotate every credential that passed through it.
Resources & References
- Kevin Beaumont / DoublePulsar: FortiBleed Primary Analysis
- Arctic Wolf Labs: Active FortiBleed Campaign Across 194 Countries
- Hudson Rock: FortiBleed Disclosure and Domain Lookup
- TechCrunch: Tens of Thousands of Fortinet Firewalls Hacked
- Triskele Labs: Fortinet Post-Exploitation Symlink Persistence
- Eclypsium: Network Infrastructure on the Front Line
- Eclypsium: A New Approach to Defending Network Infrastructure from Ransomware Groups and APTs
- Eclypsium: Pacific Rim, Chronicling a 5-Year Hacking Escapade
