FortiBleed: Not a New Vulnerability, but a Credential Lesson Organizations Must Address Now

FortiBleed is a large-scale campaign to steal and compile credentials from Fortinet devices, disclosed in mid-June 2026. **It is not a new vulnerability (CVE) and not a zero-day.** Fortinet itself confirms it stems from reusing credentials leaked in prior incidents, combined with brute-forcing devices that have weak passwords and no MFA. The immediate actions are to **reset all admin/VPN credentials, enable MFA, and remove management interface access from the internet.**

1. What FortiBleed Is (and Is Not)

In mid-June 2026, the cybersecurity community was put on alert by an event named **"FortiBleed"** — the exposure of a massive database of Fortinet device credentials that had been stolen and compiled by a threat group.

The first thing to get straight, and a point many people misunderstand, is that **FortiBleed is not a vulnerability and has no CVE identifier of its own.** The name "FortiBleed" was coined to echo "Heartbleed," a famous vulnerability from the past, which leads many to assume it is a new bug awaiting a patch. That is not the case.

Fortinet issued an official statement through its PSIRT team on June 19, 2026, stating clearly that this is not a new Fortinet vulnerability and is not related to any recent incident or advisory. Fortinet believes the activity involves threat actors reusing credentials from previous incidents (referencing advisories FG-IR-26-060 and FG-IR-25-647), combined with brute-force techniques against devices with weak password hygiene and no MFA enabled.

To put it simply: FortiBleed is not "a hole in your front door" — it is **"the keys to your house are already in the wrong hands."** This is dangerous in a different way, and the response required is different too.

2. Timeline

Date (2026)	Event
un 13	Security researcher Volodymyr "Bob" Diachenko discovers an internet-exposed threat-actor server containing a database of FortiGate admin and VPN credentials
Jun 16–19	Research teams from SOCRadar, Hudson Rock, and researcher Kevin Beaumont analyze the data and confirm that some credentials are valid and working
Jun 18	CISA (US cybersecurity agency) issues an alert urging hardening of Fortinet devices
Jun 19	Fortinet PSIRT issues its official statement, confirming this is not a new vulnerability
Jun 22	CISA updates its alert, adding a link to Fortinet's guidance

3. Scale and Scope of Impact

FortiBleed is considered one of the largest confirmed FortiGate credential exposures on record. Figures from various sources include:

- 74,000 devices affected, both firewalls and VPN gateways (figure from CISA)

- 73,932 unique firewall URLs spanning 194 countries and over 21,600 domains

- Representing roughly half of all internet-facing Fortinet devices

Affected organizations span many sectors, including government, telecommunications, finance, healthcare, manufacturing, and critical infrastructure, as well as large multinational corporations.

On attribution: Researchers assess the threat group is likely Russian-speaking, based on tooling, infrastructure, and target-selection patterns. However, this is an assessment only, not a definitively confirmed conclusion.

Important note: SOCRadar stated it found no evidence that this activity stems from a zero-day or a direct compromise of Fortinet products, attributing the exposure instead to brute-force and credential-stuffing against internet-facing Fortinet services — consistent with Fortinet's own position.

4. Technical Mechanics — How FortiBleed Works

This section is the technical heart that engineering teams should understand, because it explains why simply "patching" is not enough.

4.1 Starting Point: Extracting the Configuration File

FortiGate devices store all settings in a configuration file, which **includes the hashes of admin passwords.** When an attacker can access and extract this config file (whether through an older vulnerability, a management interface exposed to the internet, or credentials obtained earlier), they gain both network topology information and the raw material for cracking passwords at the same time.

4.2 The Structural Weakness: SHA-256 vs PBKDF2

This is the crux of the matter. Fortinet previously stored admin password hashes using the SHA-256 (with salt) algorithm, which can be cracked offline relatively quickly with modern tools.

Fortinet later switched to PBKDF2 , which is far more resistant to brute-forcing, with support introduced starting in FortiOS versions 7.2.11, 7.4.8, and 7.6.1 onward.

Note on versions: The numbers above (7.2.11/7.4.8/7.6.1) are the first versions to support* PBKDF2. The recommendation in Section 7 to upgrade to the 7.4, 7.6, or 8.0 branches refers to the version branches Fortinet recommends upgrading to (the latest release in each branch naturally supports PBKDF2). The two sets of numbers therefore do not conflict.

But the problem lies in the migration step: when upgrading from an older version, existing admin passwords **remain stored as SHA-256 hashes until that admin successfully logs in after the upgrade, at which point the system converts the hash to PBKDF2.

The consequence is that many organizations that have "already upgraded the firmware" but whose admins have not logged in again still store passwords using the weaker SHA-256 — and become immediate targets if a config file leaks.

4.3 What Hardening Engineers Must Know: The Hidden `old-password` Setting

There is a critical detail that many people overlook: even after a password has been upgraded to PBKDF2, **the original SHA-256 hash is still retained in a hidden setting called `old-password`** for backward compatibility.

- This `old-password` setting is not visible from the normal admin interface , but it appears in a config backup taken by a super_admin.

- On FortiOS v7.2.x and v7.4.x, to fully remove the legacy SHA-256 hashes, you must enable the **`login-lockout-upon-weaker-encryption`** setting in `system password-policy`.

This means that even if you believe the system is using PBKDF2, a config backup may still contain the old-style hash hidden within — and if that file leaks, attackers can still crack it.

4.4 Offline Cracking — Why Patching Alone Is Not Enough

Once attackers have the hashes, they crack them offline on their own machines, which completely bypasses protective mechanisms such as rate-limiting or account lockout that only operate during live login attempts. Once cracked, they obtain passwords that genuinely work to log into the device.

5. Why FortiBleed Is Harder to Contain Than a Typical CVE

This is the most important conceptual point of the entire event.

A typical CVE gives defenders a clear scope: they know which versions are at risk (unpatched versions) and have a clear deadline (the patch release date). Once patched, it is over.

But FortiBleed is fundamentally different, because it is a credential problem, not a software problem. The key differences:

- The patch window is bounded, but the credential window is unbounded — stolen passwords will keep working indefinitely, even after you have updated software for every CVE, until you rotate (change) every credential yourself.

- Hard to detect — an attacker logging in with correct credentials "looks like normal admin activity" in every respect. There is no exploit code to catch at the perimeter and no malware signature to match. Detection requires behavioral analysis of authentication patterns and configuration changes.

- Risk of lateral movement — once attackers gain admin rights on a firewall, they typically do not stop there, but use it as a beachhead to push into Active Directory and the internal network.

In short: an organization that patches every CVE this week but does not rotate credentials and enable MFA remains at risk.

6. Was Your Organization Affected — How to Check

Conditions That Put You at Risk

Your organization is in the at-risk group if:

- You operate a FortiGate with its management interface (web console, SSH) or SSL VPN endpoint directly reachable from the internet

- You have upgraded FortiOS from an older version, but some admin accounts have not logged in again after the upgrade (passwords still stored as SHA-256)

- You have not enabled MFA on admin and VPN accounts

- You were attacked or had a vulnerability in the past, but at the time "patched without changing passwords"

What to Check in Your Systems

1. Review the config for unauthorized users or changes, comparing against a known-good backup configuration.

2. Watch for rogue accounts that may have been created, especially names attempting to impersonate system accounts such as `forticloud`, `fortiuser`, `fortinet-support`, `fortinet-tech-support`.

3. Check logs for admin-level access from unknown IP addresses.

4. Check domain controller logs for signs of lateral movement, abnormal access, suspicious accounts, or unauthorized config changes.

5. If AD/LDAP integration is configured, treat that account as potentially compromised and monitor for its use to authenticate elsewhere or to create additional accounts.

7. Remediation — Action Plan per Official Guidance

The following are the 6 urgent steps per official guidance from Fortinet PSIRT, ordered by priority:

Do Immediately (Critical)

1. Terminate sessions and reset all credentials

Terminate all active admin sessions, then reset all VPN and admin passwords, especially on internet-facing systems, and enforce a strong password policy.

2. Enable MFA

Enable Multi-Factor Authentication on all administrator and VPN user accounts — this step dramatically reduces the effectiveness of stolen credentials, even if attackers possess valid passwords.

3. Lock down / restrict management interface access

Reduce the attack surface by restricting device management, in order of increasing security:

- Good: restrict via trusted hosts

- Better: use a local-in policy

- Best: remove internet-based management entirely

Do Next (Important)

4. Upgrade and purge old hashes

Upgrade to the latest versions of 7.4, 7.6, or 8.0, which support PBKDF2 hashing, then follow the guidance to remove legacy password settings via `set login-lockout-upon-weaker-encryption`.

> Important: after upgrading, all admins must log in at least once so the system converts the hash to PBKDF2. If that is not feasible, have a super_admin manually update the passwords of the remaining admins.

5. Validate configuration

Review firewall users, VPN users, and other config for unauthorized changes (see details in Section 6).

6. Check logs

Look for admin-level access from unexpected IPs/domains, and check domain controller logs for lateral movement.

if You Find Evidence of Compromise (IoC)

If you find unauthorized config modifications or other IoCs, treat the device as compromised and follow Fortinet's recovery procedures. Check for the creation of VPN users, unexpected password resets, or VPN logins from unexpected locations, which may indicate the attacker has attempted to move into the internal network.

8. Summary — Key Takeaways

- FortiBleed is not a new vulnerability, and no patch will close it — it is a problem of leaked, reused credentials.

- Patching alone is not enough — you must rotate every credential, because leaked ones keep working until changed.

- MFA is the most important shield — it protects even in cases where a password has already leaked.

- Reduce the attack surface — do not expose management interfaces or SSL VPN to the internet unnecessarily.

- Don't forget the hidden hash — after upgrading, all admins must log in again, and consider enabling `login-lockout-upon-weaker-encryption` to purge the legacy SHA-256 hashes.

This event is a reminder that perimeter device security does not end with "updating the version" — it must equally cover credential hygiene, MFA, and attack surface reduction.

9. References

Official Sources (Primary)

- Fortinet PSIRT — "Analysis of Reported Credential Compromise of FortiGate Devices" (Jun 19, 2026)

https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices

- CISA Alert — "CISA Urges Hardening Fortinet Devices After Reports of Credential Exposure" (Jun 18, 2026)

https://www.cisa.gov/news-events/alerts/2026/06/18/cisa-urges-hardening-fortinet-devices-after-reports-credential-exposure

Technical Analysis Sources (Secondary)

- Arctic Wolf — Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries

- Recorded Future (Insikt Group) — FortiBleed Campaign Exposing Credentials for 73,932 FortiGate Systems

- Bitdefender — Technical Advisory: FortiBleed Credential Exposure Campaign

- Censys — June 19 Advisory: Fortinet Credential Exposure Campaign

- SOCRadar Threat Research Unit (STRU)

- Hudson Rock

This document compiles information from reliable public sources as of June 2026. The situation may continue to be updated; please check the latest advisories from Fortinet PSIRT and CISA before taking action.