FortiBleed: 75,000 Firewalls at Risk from Stolen Credentials,…

FortiBleed hits already-patched FortiGate devices: credentials stolen in prior incidents enable administrative access without exploiting new vulnerabilities.

On June 17, 2026, the Qualys Threat Research team published a report on FortiBleed: a large-scale abuse campaign against internet-exposed FortiGate management and SSL-VPN devices. On June 18, CISA and the UK NCSC issued guidance for hardening and investigation. On June 19, Fortinet confirmed the analysis. The stakes are a technical paradox that breaks the patching defense model: technically updated devices remain vulnerable if legacy credentials and hashes have not been migrated.

Key Takeaways

FortiBleed is credential reuse and brute-force, not a new zero-day vulnerability: Qualys and Fortinet document this explicitly.
Credentials originate from incidents FG-IR-26-060 and FG-IR-25-647, with CVE-2026-24858 and CVE-2025-59718 cited as sources of reused credentials.
Reported figures range from ~30,800 validated records in a subset, ~74,000 cited by CISA, ~75,000 devices in independent analysis, ~73,900 unique firewall URLs, and 86,644 records in other reporting: heterogeneous numbers for different objects, snapshots, and methods, not to be combined.
A patched device can remain exposed if credentials or configuration material were copied before remediation, especially where PBKDF2 migration and legacy-hash cleanup are incomplete.

The Mechanism: Old Credentials, "New" Devices

The campaign does not exploit a fresh vulnerability. According to the Qualys advisory, FortiBleed is "driven by credential reuse and brute-force, not a single new zero-day." Fortinet echoed: "This is not a new Fortinet vulnerability, and this activity is not related to any recent incident or advisory."

The credential source vectors are documented. CVE-2026-24858, rated CVSS 9.8 CRITICAL per the NVD record, is an authentication SSO bypass that Fortinet cites as a source of reused credentials in the June 2026 campaign. CVE-2025-59718, also CVSS 9.8 CRITICAL, is a FortiCloud SSO SAML bypass, explicitly cited as a "reused-credential source." CVE-2025-59719, a paired advisory for FortiWeb/SSO inventory, completes the cluster. These CVEs are not the active June vector: they are the provenance of the credentials fueling the attack.

The operational mechanism is twofold. Attackers combine credential reuse — credentials stolen in prior incidents — with brute-force and password-spraying against internet-exposed administrative interfaces. No exploit is needed: only that credentials remain valid or that legacy hashes are crackable.

The Unmigrated PBKDF2 Trap

Here lies the technical core of the "patching illusion." FortiOS introduced PBKDF2 for credential hashing, deprecating legacy algorithms. But migration is often incomplete: legacy hashes can persist in uncleaned configurations, backups, redundant systems, or instances untouched by the upgrade.

Qualys writes: "A patched device can remain exposed if credentials or configuration material were stolen before remediation, especially where PBKDF2 migration and legacy-hash cleanup are incomplete." Fortinet confirms the same guidance. The result is that an administrator who updated FortiOS to the correct version — 7.4, 7.6, or 8.0 with PBKDF2 enabled — can still see their device compromised if credential rotation is not accompanied by configuration verification and active session termination.

Persistence is the most insidious problem. If an attacker has already gained administrative access, they may have modified the configuration, installed alternative access mechanisms, or exfiltrated integrated authentication material — AD, LDAP, RADIUS — that survives a local password change.

"factory reset the device, as changing credentials alone may not be sufficient if threat actors have obtained persistence on the device"
— UK NCSC Alert

The Scale: Numbers That Don't Add Up

Public reporting has produced impressive figures that, however, do not describe a homogeneous universe. Qualys lists multiple figures with an explicit caveat: "~30,800 validated records in a subset," "~74,000 records reported by CISA," "~75,000 devices in independent analysis," "~73,900 unique firewall URLs," "86,644 records in other reporting." The primary source warns that these numbers "reflect different objects, snapshots, validation claims, and deduplication methods" and should not be combined.

What this means in practice: ~73,900 unique URLs are exposed endpoints, not necessarily compromised. ~30,800 validated records are a subset with a verification claim, not a global count. The ~74,000 cited by CISA and the 86,644 from other reporting use undetailed objects and methods. There is no consolidated number of actually breached devices, and the dossier does not provide one.

What to Do Now

Fortinet specifically recommends: terminate all active sessions, perform credential resets, implement MFA, update to versions 7.4/7.6/8.0 with PBKDF2 enabled, validate configuration, review logs, and reduce the attack surface by exposing fewer management interfaces to the internet.

NCSC adds a more radical recommendation: if compromise is suspected, "factory reset the device, as changing credentials alone may not be sufficient if threat actors have obtained persistence on the device." The factory reset is the only guarantee to eliminate hidden persistence mechanisms in modified configurations.

Fortinet has also stated: "Fortinet has identified the potentially compromised systems, and we are proactively contacting impacted customers and will complete outreach in the days to come." Organizations with exposed devices should verify whether they have received direct communication.

The dossier does not specify how many devices with unmigrated legacy hashes are actually exposed, nor whether credentials from CVE-2018-13379 — the 2018 vulnerability rated CVSS 9.1 CRITICAL — remain valid in current target systems. These points remain to be verified case by case.

Why This Case Reveals a Systemic Failure

FortiBleed is not a zero-day story. It is a story of technical debt in cryptography configuration that becomes an active vulnerability. PBKDF2 migration was technically available, but its incomplete implementation — persisted legacy hashes, unrotated credentials, unterminated sessions — creates an exposure window that survives patching.

The case highlights three recurring failures in the enterprise perimeter: exposure of management interfaces to the internet, absence of MFA on critical systems, and credential reuse across incidents without programmatic rotation. These are not software bugs: they are hygiene errors that accumulate into technical debt and activate when the threat landscape meets them.

For the industry, the message is that patching is a necessary but insufficient condition. Complete remediation requires credential auditing, cryptographic migration verification, and — in case of confirmed compromise — factory reset with configuration rebuild from a trusted baseline. The operational cost is higher than a simple update, but it is the only way to close the window that patches alone leave open.

Information is based on the cited source and current as of publication.

Sources

Sources and references