A fresh investigation codenamed FortiBleed 2.0 has unearthed more than 40,000 exposed credentials in misconfigured FortiGate firewall configurations—ranging from local-user passwords to Active Directory (AD) LDAP binds. The revelations shed light on widespread risk for both VPN access and internal directory services.
What Was Discovered
Researchers reviewed 1,703 configuration-report files tied to FortiGate devices, covering over 100,000 credential and account records across nearly 1,700 host identifiers. In total, 40,573 of those records were in cleartext. Among them were 37,076 local-user passwords and 1,576 LDAP bind credentials that link firewall, VPN, and internal identity systems. Also exposed were admin logins, email-server credentials, and high-availability cluster secrets—which, while reflective of data within these configs, don’t necessarily mean the credentials are currently active or tied to unique users or devices.
Though the title suggests a fresh vulnerability, FortiBleed 2.0 isn’t about a newly found security flaw. Instead, it builds on earlier leaks: most of the files date back to February 20, 2026, while 31 remain undated. Exactly when the data was accessed or stolen remains unclear.
Expanded Scope & Technical Details
Compared to original FortiBleed findings, this second wave reveals almost 1,000 additional host identifiers and nearly as many new domain labels. Still, not all domain labels equate to new breached companies—some belong to registrar or registration contacts. These configurations allow tools to pull in local users, admin accounts, cluster secrets, email credentials, and LDAP configuration elements.
Particularly worrisome are LDAP bind credentials, which permit FortiGate devices to communicate with directory services; compromise here could grant attackers deeper network footholds. Offline recovery of encryption-protected secrets is possible if device configs still use system-default keys—depending on device and software version.
What Organizations Must Do Now
Fortinet advises immediate action: terminate all active admin and VPN sessions, reset credentials, enforce or audit multifactor authentication, update relevant FortiOS firmware, and limit management interface access. Security teams are urged to compare current configurations with trusted backups, scrutinize emails and LDAP secrets, and investigate domain-controller logs for anything unusual.
Disabled local-user records—some 7,437 of them in the FortiBleed 2.0 data—were found with cleartext passwords. Absence of seen MFA doesn’t always mean accounts lack protection, as external systems might enforce it. Account names alone are unreliable indicators of compromise—frequently-used names like “fgtsecure” or “forticloud-sync” should be verified rather than automatically assumed malicious.
This incident is the latest sign of how dangerously exposed credentials, especially in VPNs and directory services, can escalate risk in enterprise environments. When secrets are stored insecurely—particularly with default encryption or offline recoverable keys—it opens up paths to major breaches.
Why It Matters: The FortiBleed 2.0 leak underlines a larger trend: organizations are still leaving critical credentials, including admin and LDAP secrets, in plaintext or weakly protected state within firewall configurations. VPN and AD compromise often serve as stepping stones into internal systems, which makes such exposure especially severe. Going forward, companies should treat firewall configs as high-risk assets, use strong encryption for stored secrets, and routinely audit for latent exposures. What to watch: are any of these revealed credentials found in the wild? Has there been evidence of active abuse? And will Fortinet make changes—beyond advisories—to enforce more secure defaults?
