FortiBleed explained: old Fortinet exposure, fresh credential risk

FortiBleed is the kind of story that gets noisy quickly: big numbers, famous company names, raw-dump curiosity, and a lot of recycled vulnerability names. The useful work is quieter. Separate what is known from what is claimed, decide what defenders should do now, and avoid turning stolen credentials into spectacle.

Published: 18 June 2026 Updated: 19 June 2026 Prepared by: Chill Ethical People — Threat Intelligence Unit Handling note: This version is written for defensive awareness. It does not include raw credential data, retrieval paths, or instructions for accessing stolen material.

---

Executive Summary

FortiBleed is best understood as a Fortinet credential-exposure event, not as proof of a new Fortinet zero-day. Public reporting indicates that attacker-operated infrastructure exposed a large dataset of Fortinet/FortiGate VPN and firewall access records. The most important defensive lesson is boring and urgent: patching perimeter appliances is not enough if credentials, configuration-derived secrets, MFA material, and management exposure are left behind.

For threat intelligence analysts, the story matters because it shows how old edge-device compromises can be recycled into new access-brokerage activity. For blue teams and security operators, the priority is not to chase the raw dataset. The priority is to rotate credentials, restrict management surfaces, verify FortiOS password-hash migration, hunt for persistence, and review authentication logs.

Quick Answers

At a Glance

Key Takeaways

• FortiBleed is an actionable credential-risk event, even if it is not a newly confirmed vulnerability.
• Old Fortinet exposure can stay useful when organizations patch devices but do not rotate credentials or invalidate secrets.
• Configuration material can expose more than passwords: topology, integration context, certificates, keys, and account patterns.
• Infostealer output and credential stuffing can bypass appliance-side password-storage improvements.
• The right response is operational: rotate, restrict, rehash, review logs, remove persistence, and monitor for access-brokerage reuse.

Who This Blog Is For

This analysis is written for:

• Threat intelligence analysts who need to separate evidence from recycled vulnerability keywords.
• Blue teamers who need a defensible triage plan without touching raw stolen data.
• Security operators responsible for FortiGate, SSL VPN, identity, and edge-device administration.
• Incident responders validating whether old Fortinet exposure has become current credential risk.
• Security leaders deciding whether this is a patching issue, a credential issue, or both.

---

Current Assessment

Analyst Bottom Line

FortiBleed should be treated as an actionable credential-exposure event, not as a newly confirmed Fortinet zero-day. Public reporting indicates that a large dataset of Fortinet/FortiGate VPN and firewall access records was exposed from attacker-operated infrastructure. The strongest defensive lesson is plain: perimeter-device patching is not enough if credentials, configuration-derived secrets, and management exposure are left behind.

On 17 June 2026, security researcher Volodymyr "Bob" Diachenko publicly disclosed the discovery of an exposed server containing what he described as valid Fortinet VPN credentials. Hudson Rock reported 73,932 unique firewall URLs across 194 countries and 21,632 unique domains. SOCRadar separately frames the event as affecting 80,000+ Fortinet firewalls/devices. These figures likely differ because sources are counting URLs, IP addresses, domains, devices, and credential records differently.

The exposed dataset is currently assessed as a convergence of multiple credential sources rather than a single root cause: prior Fortinet-related leaks, possible configuration-derived material, infostealer output, credential stuffing, brute force, and reported offline cracking activity. Fortinet has stated that its investigation points to data from previous incidents and brute forcing, not a recent breach or newly disclosed advisory.

Public reporting names major enterprises and government entities as appearing in the dataset. Appearance in the dataset should not be interpreted as proof of deep intrusion. It does, however, justify immediate credential rotation, MFA enforcement, management-interface restriction, log review, and dark-web monitoring.

Confidence and Caveats

---

Why FortiBleed Matters

The easy version of the story is "Fortinet credentials leaked." The more useful version is that FortiBleed shows how perimeter-device risk compounds over time.

Firewalls, VPN gateways, and edge appliances sit in privileged places. They authenticate users, bridge internal and external networks, and often carry configuration secrets that do not rotate as often as ordinary passwords. When these systems are exposed, the fallout can outlive the original CVE. A patched appliance can still be risky if old administrator credentials, VPN accounts, API tokens, SSO settings, configuration backups, or persistence artifacts remain valid.

That is why FortiBleed should be handled as a credential and exposure-management problem, not only as a vulnerability-management problem. The question for defenders is not "Which keyword is trending?" The question is "Could old Fortinet access material still work against us today?"

FortiBleed Timeline

---

How the Credential Pool Likely Formed

FortiBleed is not currently tied to a single newly disclosed vulnerability. Public reporting supports a more practical assessment: the dataset appears to combine several collection paths that all point back to exposed edge infrastructure and stale access material.

First: Internet-Wide Reconnaissance

Diachenko reported that the operators conducted large-scale scanning and credential validation against exposed Fortinet appliances, focusing on common management and SSL VPN ports:

• Port 443 (default HTTPS / SSL VPN)
• Port 4443 (alternate SSL VPN)
• Port 8443 (alternate management)
• Port 10443 (alternate management)

The reported scanning set included 320,777 FortiGate targets and 163,650 Microsoft SQL Server systems, suggesting the same tooling or operator group may have been used for broader credential-validation activity beyond Fortinet.

Then: Credential Sourcing

The available reporting points to three likely credential pools. These should be treated as collection hypotheses unless an affected organization can validate the path from its own logs.

Historical Fortinet Breach Data

The operators appear to have incorporated credentials and configuration material from earlier Fortinet-related compromises:

The Belsen Group dump is significant because configuration files can contain much more than login strings: management context, firewall rules, routing information, VPN settings, certificates or keys, and references to LDAP/RADIUS integrations. Even when passwords are rotated, old configuration material can still help an actor understand how to approach a target.

Infostealer Malware Harvests

The second likely credential pool is endpoint-level infostealer output. When infostealer malware captures credentials from a browser, password manager, or endpoint application, those credentials are collected before FortiGate-side password storage controls matter. Strong password hashing on the appliance does not protect a password already stolen from an operator workstation.

Active Brute-Force and Credential Stuffing

Where historical or infostealer-sourced credentials failed, Diachenko reported large-scale brute-force and credential-stuffing activity:

• 1.16 billion authentication attempts against 320,777 FortiGate targets
• 2.1 billion brute-force attempts against 163,650 MSSQL servers

The credential-stuffing activity reportedly emphasized default and common administrator patterns. SOCRadar's analysis found that generic "admin" variants constituted 21.43% of compromised accounts, indicating that default-account hygiene remains a meaningful exposure factor.

Then: SSL VPN Hash Interception and Offline Cracking

For targets where credential stuffing failed, Diachenko reported a more technical collection path: interception of SSL VPN authentication challenge-response hashes followed by offline cracking.

Captured hashes were cracked offline using:

• A 45-GPU compute cluster (likely rented cloud GPU infrastructure)
• Hashtopolis — an open-source distributed hash-cracking management framework
• Targeting SHA-256 with Salt hashes from legacy FortiOS password storage

The SHA-256 Hashing Weakness

This is one plausible amplifier for the incident, especially where attackers obtained configuration files or legacy password material:

Prior to FortiOS 7.2.11 / 7.4.8 / 7.6.1, Fortinet administrator password storage relied on SHA-256 with salt rather than a slower password-hashing construction. SHA-256 is fast by design, which makes exposed hashes easier to attack offline with GPU infrastructure than hashes protected with PBKDF2, bcrypt, scrypt, or Argon2-style controls.

Fortinet introduced PBKDF2-based password hashing (a proper key-derivation function with configurable iteration count) in:

Operational caveat: after upgrading, older password material may persist until administrators re-authenticate or enforcement controls are applied. Rarely used accounts such as service, backup, or break-glass administrators are therefore easy to miss during migration.

Public Fortinet guidance discusses controls for weaker administrator password encryption. For defenders, the practical issue is simple: if configuration backups or old password fields contain legacy hashes, then config theft can become credential theft even after patching.

The result is a durable risk pattern: configuration exposure plus fast legacy hashes can turn old appliance access into fresh valid credentials.

If Access Worked: Passive Traffic Collection

Some public reporting claims that compromised devices were used for passive traffic collection. This should be treated as medium-confidence until validated in local evidence. If true, the risk is material because FortiGate devices often sit where authentication and remote-access traffic crosses the perimeter:

• Internal authentication traffic (NTLM, Kerberos)
• VPN user credentials
• LDAP and RADIUS bind requests
• Application login credentials
• Service account credentials
• API keys and tokens

This would create a self-reinforcing loop: one compromised perimeter device can expose additional credentials, which can then be tested against other systems.

Finally: Packaging for Access Brokerage

The annexed victim-list review indicates that each exposed record may include a mixture of access data and targeting context:

The formatting is consistent with access-brokerage workflows: sort by organization, sector, geography, and financial profile; validate working access; then package the result for resale or follow-on intrusion. As of the cited reporting window, SOCRadar and Hudson Rock had not observed the FortiBleed dataset offered publicly for sale, but private distribution remains plausible.

---

Why This Stayed Dangerous

The FortiBleed incident is best understood as a convergence of operational and architectural weaknesses. No single control failure explains every record in the dataset.

Legacy Password Hashing

Legacy SHA-256-based administrator password storage is an exposure amplifier when configuration files or hashes are stolen. Fortinet's later PBKDF2 migration improves the control posture, but defenders still need to force re-authentication, purge weaker legacy material, and inspect backups for stale password fields.

Patch Lag Without Credential Rotation

The Fortinet CVE chain (2022-40684 -> 2022-42475 -> 2023-27997 -> 2024-21762 -> 2024-55591 -> 2026-24858) shows a recurring edge-device problem: organizations patch the appliance but do not always rotate credentials, remove persistence, restrict management access, or invalidate secrets exposed through configuration material. The Belsen Group's January 2025 dump contained data reportedly harvested via a vulnerability patched in October 2022, illustrating how old appliance exposure can stay useful long after a patch window closes.

This pattern is not unique to Fortinet. Similar SonicWall SSL VPN activity in 2025 showed that patching an edge device does not automatically invalidate access material already stolen from it. In Akira-linked SonicWall cases, public reporting described follow-on access through legacy credentials, migration-era accounts, and in some cases OTP seed material even where appliances had been patched. The lesson is the same: patching closes the software flaw; it does not rotate passwords, invalidate stolen MFA material, remove persistence, or restrict exposed management surfaces.

Default Account Persistence

SOCRadar's finding that 21.43% of compromised accounts used "admin" variants suggests that default-account naming and weak credential hygiene remain part of the exposure pattern. This does not prove factory defaults were still in use everywhere, but it is enough to justify account-name review and administrator rotation.

Exposed Management Interfaces

The operation was made easier by internet-reachable FortiGate management and SSL VPN surfaces. Public exposure does not equal compromise, but it gives attackers the scanning, stuffing, and validation surface they need.

---

Raw Leak Data: Availability and Handling

Discovery: The Exposed Attacker Server

The FortiBleed dataset was not initially reported as a public forum dump. Diachenko reported discovering it on a misconfigured server operated by the attackers, with directory indexing enabled. The server reportedly exposed operational infrastructure and data:

This appears to be an attacker OPSEC failure, not an intentional public release. The report should not include retrieval instructions for stolen data.

Current Data Availability

Prior Leak: Belsen Group Dump (January 2025)

The Belsen Group's January 2025 dump is separate from FortiBleed but contextually relevant. It was reported as a 1.6 GB archive of approximately 15,000 FortiGate configurations organized by country and victim IP. This report does not provide access paths to that material.

Critical distinction: FortiBleed (June 2026) and the Belsen Group dump (January 2025) are separate datasets with reportedly non-overlapping IP addresses and different FortiOS version profiles. Belsen Group data is best treated as a plausible historical input to FortiBleed-style credential stuffing, not as proof of the same actor.

Analyst Handling Guidance

• Do not download, mirror, or redistribute raw credential data.
• Use ethical lookup or disclosure channels to determine exposure.
• Treat a positive domain match as sufficient reason for rotation and log review, even if raw credentials are not available.
• If raw data is received through a legal or incident-response channel, handle it as sensitive incident evidence, not as open-source reporting material.

---

Attribution: Keep It Boring

Attribution should remain cautious. The public evidence supports an organized credential-harvesting and access-brokerage operation. It does not support confident attribution to a named intrusion set.

Campaign-correlation note: the strongest correlation pivots are victimology and capability: Fortinet edge devices, exposed management/SSL VPN surfaces, credential reuse, configuration-derived context, and repeated exploitation of perimeter appliance weaknesses. Infrastructure and named-actor pivots remain weak in public reporting.

---

FortiBleed Impact

Scale

Geographic Distribution

India and the United States together account for nearly one-third of all entries.

Sector Distribution

Named Organizations in the Dataset

Appearance in the dataset does not prove deep intrusion. It indicates that public reporting named the organization as appearing in exposed Fortinet-related records.

Low-confidence entries come from single-source or aggregated reporting and should be verified through ethical disclosure channels before reuse in derivative reports.

---

ATT&CK Mapping

---

Prior Fortinet Vulnerabilities

FortiBleed should not be viewed in isolation. It reflects a four-year vulnerability and credential-reuse chain around Fortinet products:

Across this chain, prior vulnerabilities and leaks produced credentials, configurations, or persistence opportunities that could be recycled into later operations. Organizations that patched one vulnerability but failed to rotate credentials, remove persistence, and restrict management access remained exposed to the next phase.

---

Fortinet's Response

Fortinet's official statement characterized the data as:

"A resharing of data from previous incidents, as well as bruteforcing of credentials, and is not related to any recent incident or advisory."

This framing is useful but incomplete for defenders. Even if the dataset is derived from prior incidents and brute forcing, credentials and configuration-derived secrets can remain operationally valid long after the original vulnerability is patched:

• Kevin Beaumont publicly assessed that the dataset appears legitimate and recent, and that many listed devices remained online.
• The Belsen Group case showed that "old" Fortinet configuration material may remain useful when credentials, keys, or management exposure are not fully remediated.
• Infostealer-sourced credentials, default admin naming, weak legacy password material, and exposed management surfaces are ongoing operational risks, not merely historical artifacts.

---

What Defenders Should Do

Immediate Actions: 0-48 Hours

1. Determine exposure — Check organizational domains against the Hudson Rock FortiBleed lookup tool (hudsonrock.com/fortinet).

1. Rotate all Fortinet-adjacent credentials — Change every administrator, VPN user, and service account password on all FortiGate devices. This includes:

• Local admin accounts
• LDAP/RADIUS-bound accounts used for VPN authentication
• API keys and automation credentials
• FortiCloud SSO credentials

1. Force PBKDF2 migration — On FortiOS 7.2.11+, 7.4.8+, or 7.6.1+:

• Require all admin accounts to re-authenticate (forces PBKDF2 rehash)
• Enable login-lockout-upon-weaker-encryption in system password-policy to purge residual SHA-256 old-password entries
• Verify via config backup that no old-password fields remain

1. Enforce MFA — Enable two-factor authentication on all FortiGate management and SSL VPN interfaces immediately.

1. Restrict management access — Apply local-in policies to limit management interface access to trusted internal IP ranges only. No FortiGate management interface should be reachable from the public internet.

1. Disable FortiCloud SSO if not essential, given CVE-2026-24858.

Short-Term Actions: 1-2 Weeks

1. Audit login history — Review FortiGate logs for:

• Successful authentications from unexpected geographic locations
• Admin sessions outside business hours
• Multiple failed authentication attempts followed by success
• Configuration downloads or backups by unusual accounts
• New admin accounts or privilege escalations

1. Hunt for persistence — Check for the SSL-VPN symlink persistence technique (disclosed April 2025) where threat actors created symbolic links connecting user and root file systems in SSL-VPN language file directories. This backdoor survives patching of the original vulnerability.

1. Update FortiOS — Ensure all devices are running at minimum:

• FortiOS 7.2.11 or later (7.2.x branch)
• FortiOS 7.4.8 or later (7.4.x branch)
• FortiOS 7.6.1 or later (7.6.x branch)
• FortiOS 8.0.0 (current branch, if supported by hardware)

1. Rename default accounts — Rename or disable all default admin accounts and create uniquely named administrator accounts.

Strategic Actions: 1-3 Months

1. Deploy network-layer credential monitoring — Implement detection for LDAP, RADIUS, and Kerberos credential exposure on networks behind FortiGate devices, given the passive sniffing capability described in Phase 4.

1. Implement configuration integrity monitoring — Deploy automated tools to detect unauthorized configuration changes, backup exports, or new admin account creation on FortiGate devices.

1. Review edge-device risk ownership — Organizations with critical Fortinet exposure should evaluate whether patching, credential rotation, configuration review, and access restrictions are owned clearly enough to prevent old edge-device incidents from becoming new credential incidents.

1. Monitor dark web — Engage threat intelligence services to monitor for the FortiBleed dataset appearing on criminal forums, access brokerages, or ransomware operator channels.

---

Detection Notes

Attacker Infrastructure

Detection Opportunities

Network-Level Indicators

Monitor for outbound connections from FortiGate management IPs to:

• Known Hashtopolis C2 infrastructure
• Unusual cloud GPU provider IP ranges
• Data exfiltration to new/unknown destinations post-compromise

---

What Not To Do

• Do not chase raw credential dumps. Use ethical lookup and disclosure channels.
• Do not treat "not named publicly" as "not exposed." Publicly named organizations are a small subset of the reported dataset.
• Do not treat patching as credential rotation. Patch the device, then rotate credentials and invalidate config-derived secrets.
• Do not publish victim names without confidence labels and source context.
• Do not over-attribute. The public evidence supports an access-brokerage pattern, not a clean named-actor call.

---

FAQ

What is FortiBleed?

FortiBleed is the community name for a June 2026 Fortinet credential-exposure event involving reported FortiGate firewall and VPN access records. It is not currently best described as a newly confirmed Fortinet zero-day. The stronger public assessment is that the dataset reflects a convergence of prior Fortinet exposure, credential stuffing, possible configuration-derived material, infostealer-sourced credentials, and weak edge-device hygiene.

Is FortiBleed the same as the Belsen Group Fortinet dump?

No. The Belsen Group dump from January 2025 and FortiBleed from June 2026 should be treated as separate datasets unless an affected organization can prove overlap in its own evidence. The Belsen dump remains relevant because old FortiGate configuration material can feed later credential-stuffing, targeting, and access-brokerage workflows.

What should Fortinet customers do first?

Rotate all Fortinet-adjacent credentials, including local administrators, VPN users, service accounts, API keys, FortiCloud SSO credentials, and identity-provider accounts used for VPN access. Then restrict management interfaces, enforce MFA, verify FortiOS password-hash migration, and review logs for successful authentication from unusual sources.

Does patching FortiOS fix FortiBleed risk?

Patching is necessary but not sufficient. Patching closes known software flaws, but it does not automatically rotate stolen credentials, invalidate leaked configuration secrets, remove persistence, rehash old password material, or restrict exposed management interfaces.

Should defenders search for the raw FortiBleed leak?

No. Raw stolen credentials should not be downloaded, mirrored, or redistributed. Use ethical lookup tools, legal disclosure channels, vendor guidance, incident-response partners, or law-enforcement-supported processes. Treat a confirmed domain match as enough reason to rotate credentials and review logs.

Why does this matter for blue teams?

FortiBleed is a practical example of why edge-device incidents cannot end at patch deployment. Blue teams need workflows that connect vulnerability management, identity security, configuration review, and perimeter exposure reduction. Otherwise, an old appliance incident can become a fresh valid-account problem.

---

Glossary

Suggested Social Preview

Title: FortiBleed explained: old Fortinet exposure, fresh credential risk Meta description: FortiBleed is not just another Fortinet keyword. Here is what CTI analysts, blue teams, and security operators should know about the June 2026 Fortinet credential-exposure event. Canonical keywords: FortiBleed, Fortinet credential exposure, FortiGate VPN credentials, Fortinet VPN leak, edge-device security, credential rotation, blue team response.

References

• FortiBleed leak exposes Fortinet VPN credentials for 73,000 devices — BleepingComputer
• Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries — Arctic Wolf
• FortiBleed: The Compromise of 80,000+ Fortinet Firewalls — SOCRadar
• FortiBleed: 75,000 Fortinet Firewalls Compromised — Hudson Rock
• FortiBleed: How 75,000 Fortinet Firewalls Were Silently Compromised — The CyberSec Guru
• Massive password-stealing attack hits 75k Fortinet firewalls — The Register
• Hackers leak configs and VPN credentials for 15,000 FortiGate devices — BleepingComputer (Belsen Group, Jan 2025)
• FortiBleed Attack Exposes Fortinet Firewall Credentials in 194 Countries — Hackread
• FortiBleed — 70,000+ Fortinet Firewalls Compromised — Cybersecurity News
• Sweeping Credential Heist Compromises 30K+ Fortinet Devices — Dark Reading
• Fortinet: FortiGate config leaks are genuine but misleading — The Register (Belsen Group)
• Technical Tip: Enforcing PBKDF2 for administrator accounts — Fortinet Community
• Enhanced administrator password security — Fortinet Documentation (FortiOS 7.6.1)
• CVE-2026-24858 — NVD
• Compromise and persistent access of Fortinet FortiOS products — Canadian Centre for Cyber Security

---

Information is current as of 19 June 2026. Reassessment is recommended within 72 hours because reporting around this incident is still moving.