Fortibleed. The Fortinet gates were open.
Fortinet FortiGate Credential Exposure.
Data breach | CRITICAL severity Published 2026-06-16
Executive Summary
FortiBleed is a large credential exposure and follow-on intrusion campaign affecting internet-facing Fortinet FortiGate firewalls and SSL VPN gateways. Public reporting from SOCRadar, Arctic Wolf, SecurityWeek, Help Net Security, CISA, and Fortinet describes tens of thousands of exposed or compromised Fortinet devices across 194 countries. Reported counts vary by source and collection date, from approximately 74,000 to 86,644 devices.
The campaign centers on working administrator and VPN credentials, not a single new zero-day. Fortinet states the activity involves reuse of credentials from earlier incidents and brute-force attacks against devices with weak password hygiene and no MFA. Other researchers reported that exposed configuration files and legacy salted SHA-256 password hashes allowed offline cracking at scale. Fortinet introduced PBKDF2-based administrator password storage in later FortiOS branches, but upgraded devices may retain SHA-256 hashes until administrators log in or change passwords, and older hashes may persist in old-password configuration fields.
Impact is severe because FortiGate devices sit at the network perimeter. A valid administrator credential can expose VPN access, routing tables, firewall policy, internal addressing, authentication integrations, and paths into Active Directory. Reported post-access activity includes rogue accounts, persistent VPN access, configuration changes, lateral movement, and full compromise of some organizations.
Immediate response requires terminating all active VPN and administrative sessions, rotating all Fortinet administrator and VPN credentials, enforcing phishing-resistant MFA, confirming PBKDF2 credential storage, removing legacy hashes, auditing for unauthorized accounts and configuration changes, and taking management interfaces off the public internet.
Timeline
| Date | Event | Source |
|---|---|---|
| 2025 | Fortinet guidance documents PBKDF2 administrator credential storage in FortiOS 7.2.11 and later; older branches used SHA-256 hashes identified by SH2, while PBKDF2 hashes are identified by PB2. |
[8] |
| 2026-01 | Exploitation of FortiCloud SSO authentication bypass CVE-2026-24858 is reported against Fortinet devices, including creation of new administrator accounts and configuration exfiltration. | [10], [11] |
| 2026-01-28 | SecurityWeek reports Fortinet emergency patches for CVE-2026-24858, CVSS 9.4, affecting FortiCloud SSO-enabled environments. CISA adds the CVE to KEV with a January 30 deadline for federal agencies. | [11] |
| 2026-06-16 | SOCRadar publishes its FortiBleed investigation, reporting a verified database of working Fortinet credentials across 194 countries. | [4] |
| 2026-06-17 | Kudelski Security publishes an advisory on FortiBleed, active exploitation of Fortinet infrastructure, related vulnerabilities, and observed infrastructure indicators. | [9] |
| 2026-06-18 | CISA issues an alert on leaked credentials associated with approximately 74,000 Fortinet devices and urges emergency hardening steps. | [3] |
| 2026-06-18 | Help Net Security reports nearly 74,000 Fortinet firewall and VPN gateway credentials exposed after a Russian-speaking cybercriminal group's server was found exposed. | [7] |
| 2026-06-19 | Fortinet publishes its PSIRT analysis, stating the activity is not a new Fortinet vulnerability and appears tied to credential reuse, prior incidents, brute force, weak passwords, and missing MFA. | [2] |
| 2026-06-19 | SecurityWeek reports the count at more than 86,000 devices, roughly half of internet-facing Fortinet firewalls based on Shodan polling, and cites 1.16 billion credential attempts against more than 320,000 FortiGate targets. | [6] |
| 2026-06-20 | Cloud Security Alliance publishes a research note summarizing FortiBleed mechanics, the scale of compromise, PBKDF2 migration issues, and CISA guidance. | [1] |
| 2026-06-22 | CISA revises its FortiBleed alert to incorporate Fortinet's vendor guidance. | [3] |
| 2026-06-29 | SOCRadar updates its FortiBleed post and attributes the campaign to Lynx / INC ransomware activity. Treat attribution as developing unless independently confirmed in the local intelligence program. | [4] |
Technical Analysis
Affected Systems and Software
Primary exposure applies to Fortinet FortiGate appliances and associated SSL VPN gateways reachable from the public internet, especially where web administration, SSH administration, FortiCloud access, or SSL VPN access is exposed without strong controls.
Credential-storage exposure applies to FortiOS branches that stored local administrator credentials as salted SHA-256 hashes. Fortinet community guidance identifies FortiOS 7.2.10, 7.4.7, 7.6.0, and earlier as SHA-256-based. FortiOS 7.2.11 and later introduced PBKDF2 handling, but upgraded administrator accounts may remain in SHA-256 form until a successful administrator login or password change. Fortinet community discussion also notes that prior SHA-256 values can remain in old-password configuration fields and may need explicit cleanup through password-policy settings.
A related but separate exposure is CVE-2026-24858, a FortiCloud SSO authentication bypass reported as exploited in January 2026. SecurityWeek reported fixed versions including FortiOS 7.6.6, 7.2.13, and 7.0.19; FortiManager 7.6.6, 7.2.13, and 7.0.16; and FortiProxy 7.6.6 and 7.4.13. FortiBleed should not be reduced to this CVE alone. Fortinet and multiple researchers describe the main campaign as credential-driven.
Root Cause
FortiBleed combines three failure modes:
- Internet-exposed administrative and VPN surfaces on perimeter security devices.
- Credential lifecycle failures, including default or generic usernames, reused passwords, weak passwords, stale credentials from prior incidents, and missing MFA.
- Legacy password hashing behavior in FortiGate configurations, where salted SHA-256 hashes were crackable offline and could persist after firmware upgrades.
Research sources disagree on the exact initial-access mix. Fortinet states the observed campaign is not a new Fortinet vulnerability and is based on reused credentials from previous incidents and brute-force techniques. SOCRadar, Arctic Wolf, Help Net Security, and Cloud Security Alliance describe configuration-file access and offline hash cracking as core mechanics. Both explanations can coexist: a threat actor can use leaked or brute-forced credentials to obtain configurations, crack additional hashes offline, validate credentials, and feed recovered credentials back into automated access attempts.
Attack Vector
The attack path reported across sources is:
- Identify FortiGate and SSL VPN systems exposed to the internet.
- Attempt authentication using leaked, reused, default, generic, or brute-forced credentials.
- Obtain configuration backups or administrative access where possible.
- Extract local account hashes, including
SH2salted SHA-256 values and legacyold-passwordentries. - Crack hashes offline using GPU-accelerated tooling.
- Validate recovered credentials against live FortiGate targets.
- Use valid access to create persistence, modify VPN or firewall configuration, enumerate internal networks, and pivot into identity infrastructure.
SecurityWeek and Help Net Security cited reporting that the operators used a 45-GPU Hashtopolis environment and performed approximately 1.16 billion credential attempts against more than 320,000 FortiGate targets. Kudelski published associated infrastructure indicators for open directory, credential harvesting, jump box, and Hashtopolis hosts.
Threat Actor
Attribution remains developing. Help Net Security and SecurityWeek cite researcher reporting that the campaign was operated by a Russian-speaking cybercriminal group. SOCRadar's June 29 update attributes FortiBleed to Lynx / INC ransomware activity. That attribution should be treated as unconfirmed unless corroborated by internal telemetry, incident-response findings, or trusted intelligence feeds.
The observed tradecraft is consistent with financially motivated initial-access operations: large-scale scanning, credential validation, structured victim datasets, prioritization by organization value, and possible resale or use for ransomware intrusion. FortiGate access is high-value because it can provide VPN entry and network context without deploying malware on the firewall itself.
Vulnerable Code
# Representative FortiOS configuration pattern, not a real credential.
# SH2 denotes SHA-256 storage. PB2 denotes PBKDF2 storage.
config system admin
edit "admin"
set accprofile "super_admin"
set vdom "root"
set password ENC SH2 <salted_sha256_hash>
set old-password ENC SH2 <previous_salted_sha256_hash>
next
end
# Fortinet guidance describes enabling password-policy behavior
# to remove or lock out weaker legacy hash material.
config system password-policy
set login-lockout-upon-weaker-encryption enable
end
Malware Analysis
No dedicated malware family is required for the core FortiBleed activity. The campaign is credential-led. The key artifacts are exposed credentials, FortiGate configuration data, cracked hashes, unauthorized local accounts, VPN sessions, authentication events, and infrastructure used for credential harvesting or hash cracking.
Follow-on intrusions may deploy ransomware, remote management tools, credential dumpers, or persistence tooling after access moves into Windows, Active Directory, or server environments. Those artifacts are organization-specific and should be handled through incident response rather than assumed from FortiBleed reporting alone.
Impact
End Users
FortiBleed does not primarily expose consumer data from Fortinet itself. Risk to individuals depends on whether their employer, school, healthcare provider, bank, telecom provider, or service provider operated a compromised FortiGate device and whether attackers pivoted into internal systems.
Potential downstream exposure includes corporate credentials, VPN access, internal email, files, HR records, customer records, healthcare data, and billing data. Public reporting names government, telecommunications, healthcare, finance, education, energy, and major enterprise environments among exposed sectors, but a device listed in a leaked credential set does not prove personal data theft by itself.
Affected organizations should notify users if internal investigation confirms unauthorized access to systems containing personal information. End users should reset passwords if instructed by their organization, avoid password reuse, enroll in MFA, and watch for targeted phishing that references employer systems, VPNs, invoices, benefits, or security updates.
System Administrators
FortiBleed is an emergency perimeter-device incident. Administrators should assume valid credentials may already be in circulation if a FortiGate device had internet-facing management or SSL VPN access, weak password hygiene, missing MFA, or exposure to prior Fortinet incidents.
Immediate administrative priorities:
- Terminate all active SSL VPN and administrative sessions.
- Rotate all Fortinet administrator, VPN, LDAP, RADIUS, service, and break-glass credentials tied to the device.
- Enforce phishing-resistant MFA for administrators and remote-access users.
- Upgrade FortiOS to a supported fixed release in the 7.4, 7.6, or 8.0 branches as recommended by Fortinet.
- Confirm administrator hashes use PBKDF2 and remove weaker legacy hash material.
- Review
config system admin, VPN users, local users, trusted hosts, firewall policies, static routes, address objects, automation stitches, and remote logging settings. - Search for unauthorized users such as
forticloud,fortiuser,fortinet-support,fortinet-tech-support, or other unrecognized accounts. - Move management access behind trusted hosts, a local-in policy, a bastion host, private management network, or out-of-band access path.
- Review FortiGate, VPN, authentication, and domain controller logs for unusual source IPs, impossible travel, new account creation, VPN access from unexpected geographies, and lateral movement.
If unauthorized configuration changes or unexpected accounts are found, treat the firewall and connected identity systems as compromised. Rebuild from a known-good configuration where possible, rotate directory integration secrets, review domain controller logs, and preserve evidence before wiping or reimaging.
Developers
FortiBleed is not a library vulnerability or a source-code dependency issue. Developer impact appears when applications, CI/CD systems, cloud consoles, internal package registries, or secrets-management systems are reachable through VPN paths protected by FortiGate.
Development and platform teams should verify that build systems and repositories are not implicitly trusted once a user enters the VPN. Check for access paths from VPN subnets to Git hosting, artifact registries, CI runners, Kubernetes APIs, cloud metadata services, secrets managers, and production deployment systems. Rotate secrets that could have been reached from VPN-accessible administration hosts.
Useful checks:
# Find references to FortiGate VPN source ranges in infrastructure-as-code.
grep -RInE "fortigate|fortinet|vpn|ssl.?vpn|trusted_hosts|local-in|10\.|172\.16\.|192\.168\." .
# Search CI/CD configuration for VPN-only assumptions or static credentials.
grep -RInE "VPN|FORTI|RADIUS|LDAP|password|token|secret|deploy_key" .github .gitlab-ci.yml Jenkinsfile terraform ansible 2>/dev/null
Applications should not rely on VPN presence as authorization. Enforce application-level identity, short-lived credentials, least privilege, device posture checks where available, and audit logging for administrative actions.
Proof-of-Concept and Exploit Code
No reliable public exploit proof-of-concept for CVE-2026-24858 or a FortiBleed credential-theft exploit was found in GitHub, GitLab, or Codeberg searches run on 2026-07-03. Public results were mostly low-star checker or lookup utilities.
grupooruss/FortiBleed (github — Scanner)
- Classification: Scanner
- Language: Python
- Stars: 1 — Last updated 2026-06-25T19:24:18Z
- Description: FortiBleed checker.
Usage notes: Treat as unvalidated third-party tooling. Review source before execution, avoid submitting sensitive IP ranges or credentials to untrusted services, and run only from an isolated environment.
0xhnl/fortibleed-checker (github — Scanner)
- Classification: Scanner
- Language: Python
- Stars: 0 — Last updated 2026-06-21T13:00:03Z
- Description: CLI tool to check whether domains or IPs appear in the leaked Fortinet VPN credentials corpus.
Usage notes: Treat as unvalidated third-party tooling. Prefer vendor, CERT/CSIRT, or trusted incident-response channels for exposure checks involving production assets.
Indicators of Compromise
File Hashes
None available.
Network Indicators
| Type | Value | Context |
|---|---|---|
| IP | 85.11.187.8 |
Open directory / Hashtopolis infrastructure reported by Kudelski Security. |
| IP | 85.11.187.28 |
Fortinet credential harvesting infrastructure reported by Kudelski Security. |
| IP | 193.8.187.2 |
Jump box reported by Kudelski Security. |
| IP | 185.229.26.83 |
Hashtopolis instance reported by Kudelski Security. |
| IP | 213.169.49.142 |
Hashtopolis instance reported by Kudelski Security. |
| IP | 38.117.87.37 |
Hashtopolis instance reported by Kudelski Security. |
| IP | 198.53.64.194 |
Hashtopolis instance reported by Kudelski Security. |
| IP | 175.155.64.221 |
Hashtopolis instance reported by Kudelski Security. |
YARA Rules
None found. Rules may be contributed at YARAHQ.
Suricata / Snort Signatures
None identified.
Sigma Rules
None found. Search SigmaHQ for community rules.
Threat Hunting Queries
Splunk — FortiGate administrator and VPN access anomalies
(index=fortigate OR sourcetype="fgt_traffic" OR sourcetype="fortigate")
("admin" OR "administrator" OR "SSL VPN" OR "vpn" OR "login")
| eval normalized_user=lower(coalesce(user, user_name, admin, src_user))
| eval normalized_src=coalesce(srcip, src_ip, remip, clientip)
| search normalized_user IN ("admin", "forticloud", "fortiuser", "fortinet-support", "fortinet-tech-support") OR action IN ("login", "login-failed", "tunnel-up")
| stats count min(_time) as first_seen max(_time) as last_seen values(action) as actions values(msg) as messages by dvc, normalized_user, normalized_src
| convert ctime(first_seen) ctime(last_seen)
| sort - count
Splunk — FortiGate configuration changes after suspected exposure
(index=fortigate OR sourcetype="fortigate")
("configuration" OR "config" OR "system admin" OR "password" OR "user" OR "vpn" OR "policy")
| eval normalized_user=lower(coalesce(user, admin, src_user))
| eval normalized_src=coalesce(srcip, src_ip, remip, clientip)
| search msg="*changed*" OR msg="*added*" OR msg="*deleted*" OR msg="*password*" OR msg="*administrator*"
| stats count min(_time) as first_seen max(_time) as last_seen values(msg) as messages by dvc, normalized_user, normalized_src
| convert ctime(first_seen) ctime(last_seen)
| sort first_seen
Microsoft Sentinel / Defender KQL — FortiGate suspicious admin and VPN events
CommonSecurityLog
| where DeviceVendor has "Fortinet" or DeviceProduct has "FortiGate"
| where TimeGenerated > ago(30d)
| extend UserName = tolower(coalesce(SourceUserName, DestinationUserName, RequestClientApplication, ""))
| extend SrcIP = coalesce(SourceIP, DeviceCustomIPv6Address1, "")
| where Activity has_any ("login", "admin", "vpn", "configuration", "config", "user")
or UserName in ("admin", "forticloud", "fortiuser", "fortinet-support", "fortinet-tech-support")
| summarize Count=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Activities=make_set(Activity, 20), Messages=make_set(Message, 20) by DeviceName, UserName, SrcIP
| order by Count desc
Microsoft Sentinel / Defender KQL — Known FortiBleed infrastructure contact
let FortiBleedIPs = dynamic(["85.11.187.8", "85.11.187.28", "193.8.187.2", "185.229.26.83", "213.169.49.142", "38.117.87.37", "198.53.64.194", "175.155.64.221"]);
CommonSecurityLog
| where TimeGenerated > ago(90d)
| where SourceIP in (FortiBleedIPs) or DestinationIP in (FortiBleedIPs)
| project TimeGenerated, DeviceName, SourceIP, DestinationIP, SourcePort, DestinationPort, Protocol, Activity, Message
| order by TimeGenerated desc
Mitigation and Remediation
Immediate Actions
- Terminate all active FortiGate administrative and SSL VPN sessions.
- Reset every Fortinet local administrator, VPN, service, RADIUS, LDAP, and break-glass password. Do not reuse passwords across devices.
- Enforce phishing-resistant MFA for all administrative and remote-access accounts.
- Upgrade FortiOS to current supported releases in the vendor-recommended branch. Fortinet recommends current 7.4, 7.6, or 8.0 versions for PBKDF2 support.
- Confirm local administrator credentials use PBKDF2 and clear weaker legacy hashes.
- Remove management interfaces from the public internet. Use trusted hosts, local-in policies, bastion hosts, private management networks, or out-of-band management.
- Audit for unauthorized accounts, especially generic support-style names and accounts not tied to change records.
- Compare running configuration against a known-good backup. Investigate route, policy, address object, VPN, authentication, logging, and automation changes.
- Review firewall, SSL VPN, authentication, and domain controller logs for lateral movement and suspicious access.
- If compromise is suspected, preserve logs and configurations, isolate affected access paths, rebuild from trusted firmware and known-good configuration, and rotate connected identity secrets.
Fortinet password-policy hardening should be validated in a maintenance window and tested against the running FortiOS branch:
config system password-policy
set login-lockout-upon-weaker-encryption enable
end
For some FortiOS 7.2.x and 7.4.x branches, Fortinet community guidance references the equivalent setting login-lockout-upon-downgrade. Confirm exact syntax on the target release.
Long-term Recommendations
- Maintain an authoritative inventory of all Fortinet appliances, firmware branches, management exposure, VPN exposure, MFA status, and administrator account owners.
- Disable or rename default administrator accounts where operationally supported. Remove unused built-in and generic accounts.
- Enforce unique, high-entropy credentials per appliance and rotate after staff changes, MSP changes, mergers, incident response, and major Fortinet advisories.
- Store configuration backups as secrets. Restrict access, encrypt backups, monitor downloads, and define retention limits.
- Require device administration through privileged access management, bastion hosts, hardware-backed MFA, and session recording where possible.
- Segment VPN users from administrative networks. Do not allow broad VPN access to domain controllers, hypervisors, CI/CD systems, backup infrastructure, or cloud control planes.
- Send FortiGate logs to centralized SIEM storage that attackers cannot alter from the firewall.
- Add recurring checks for internet-exposed management ports using external attack surface management and independent scans.
- Include perimeter devices in incident-response tabletops and recovery procedures. Firewalls, VPN concentrators, and identity bridges require rebuild playbooks, not only patch playbooks.
- Assess MSP and supplier access. FortiBleed reporting includes generic and service-provider-style accounts, which makes third-party credential governance a priority.
Vendor Advisories
- Fortinet — States the campaign is not a new Fortinet vulnerability; recommends terminating sessions, resetting credentials, enabling MFA, upgrading, removing legacy password settings, validating configuration, reviewing logs, and locking down management access.
- CISA — Urges immediate credential reset, PBKDF2 validation, log review, phishing-resistant MFA, and removal of public management exposure.
- Fortinet Community — Documents PBKDF2 behavior, SHA-256
SH2legacy hashes, PBKDF2PB2hashes, and password-policy settings for weaker hash removal.
References
- FortiBleed: Default Credential Exploitation and Mass Fortinet Compromise — Cloud Security Alliance (2026-06-20)
- Analysis of Reported Credential Compromise of FortiGate Devices — Fortinet PSIRT (2026-06-19)
- CISA Urges Hardening Fortinet Devices After Reports of Credential Exposure — CISA (2026-06-18; revised 2026-06-22)
- FortiBleed: 86,644 Fortinet Firewalls Compromised — SOCRadar (2026-06-16; updated 2026-06-29)
- Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries — Arctic Wolf (2026-06)
- FortiBleed: 86,000 Fortinet Device Credentials Compromised — SecurityWeek (2026-06-19)
- 74,000 Fortinet firewall credentials exposed in FortiBleed data leak — Help Net Security (2026-06-18)
- Technical Tip: Enforcing PBKDF2 as hash function for administrator accounts in FortiOS v7.2.11 and later — Fortinet Community (2025; updated comments 2026)
- Fortinet "FortiBleed" Global Compromise & Active Exploitation of Fortinet Vulnerabilities — Kudelski Security Research Center (2026-06-17)
- CVE-2026-24858: Patch Released for Fortinet FortiOS SSO Authentication Bypass — SOCRadar (2026-01-28; updated 2026-06-03)
- Fortinet Patches Exploited FortiCloud SSO Authentication Bypass — SecurityWeek (2026-01-28)