FortiBleed 2026: Over 75,000 Fortinet Firewalls Silently Compromised — INC and Lynx Ransomware Are Cashing In
FortiBleed has done what most threat actors can only dream of: quietly siphon working administrator credentials from tens of thousands of Fortinet firewalls without triggering a single alert — then hand those credentials to ransomware operators who are already encrypting endpoints across the globe. If you manage FortiGate appliances in India or anywhere in Asia Pacific, you are almost certainly in scope.
- Reports place the number of Fortinet firewalls with leaked valid admin credentials at 75,000 to 86,644 devices — roughly half the global internet-facing Fortinet fleet — across 194 countries.
- The root cause is not a traditional CVE exploit: it is a credential storage design weakness in FortiOS that persists silently through device upgrades until an administrator manually logs in again.
- FortiOS versions prior to 7.2.11, 7.4.8, and 7.6.1 stored admin passwords as weak SHA-256 hashes; attackers cracked them offline using a 45-GPU Hashtopolis infrastructure.
- INC Ransom and Lynx ransomware groups have been directly linked to the FortiBleed credential infrastructure, with at least 12 confirmed ransomware deployments resulting in hundreds of encrypted endpoints.
- Secondary CVEs actively exploited alongside FortiBleed include CVE-2026-39808 and CVE-2026-39813 (FortiSandbox command injection and authentication bypass) and CVE-2026-35616 (FortiClient EMS, CVSS 9.1, used to deploy EKZ Stealer).
- Immediate actions required: reset all FortiGate credentials, enforce MFA on every admin and VPN account, force post-upgrade logins, and upgrade to a fixed FortiOS release today.
What Exactly Is FortiBleed — and Why Is It Different?
Most high-profile firewall compromises start with a zero-day that nobody saw coming. FortiBleed is more unsettling precisely because it did not need one. Security researchers at Arctic Wolf Labs, Kudelski Security, and Bitsight identified an active, large-scale credential-harvesting campaign in mid-June 2026 that had quietly accumulated valid logins for an estimated 75,000 to 86,644 internet-facing FortiGate firewalls — approximately half the global internet-exposed Fortinet fleet spanning 194 countries.
The campaign exploits a design characteristic baked into how FortiOS handles password storage during version upgrades. Older versions stored administrator passwords as SHA-256 with salt — a hashing scheme no longer considered adequate for credential protection at scale. Fortinet migrated to the far stronger PBKDF2 algorithm in newer releases (FortiOS 7.2.11+, 7.4.8+, and 7.6.1+), but here is the critical catch: when a device is upgraded, the old SHA-256 hash is only converted to PBKDF2 the next time that specific administrator account actually logs in. If an admin never logs in post-upgrade — a scenario extremely common in stable enterprise environments — the weak hash sits there indefinitely, on a patched device, waiting to be cracked.
Attackers scanned the internet for Fortinet management interfaces, extracted configuration backups exposed via SSL VPN endpoints or misconfigured management ports, and fed the SHA-256 hashes into a 45-GPU offline cracking cluster running the Hashtopolis distributed password-cracking framework. The result: billions of password candidates tested per second, and millions of valid credentials recovered and verified at scale.
The Multi-Stage Kill Chain: From Hash Crack to Ransomware Deployment
FortiBleed is not a one-step attack. Researchers at The Hacker News, Cloud Security Alliance, and SOCRadar have mapped out a multi-stage kill chain that is now firmly in the hands of ransomware operators:
- Mass internet scanning: Attackers enumerated internet-facing FortiGate management portals — over 430,000 devices globally were scanned and catalogued.
- Configuration extraction: Configuration files were pulled via SSL VPN endpoints, legacy HTTP management interfaces, and previously disclosed vulnerabilities. Researchers report approximately 110 million credentials harvested across all platforms involved in the broader campaign infrastructure.
- Offline GPU cracking: FortiOS SHA-256 hashes were fed to Hashtopolis-coordinated GPU clusters. Six cracking infrastructure IP addresses have been published as indicators of compromise.
- Privileged access and persistence: Attackers used verified admin credentials to access FortiGate management interfaces and deployed lightweight Golang-based packet sniffers on approximately 12,000 compromised devices to passively harvest live network traffic — capturing new credentials, session tokens, and authentication data.
- Lateral movement: From the firewall, threat actors pivoted into Active Directory environments and internal network segments, establishing durable persistence via VPN tunnels and management channels.
- Ransomware handoff: Verified access was either used directly or sold through initial access broker networks. INC Ransom and Lynx ransomware affiliates have been confirmed using FortiBleed-sourced credentials, with at least 12 ransomware deployments confirmed — resulting in hundreds of encrypted endpoints across manufacturing, technology, and logistics organisations.
| CVE / Issue | Affected Product | Type | CVSS |
|---|---|---|---|
| FortiBleed (no CVE) | FortiOS / FortiGate | Credential storage weakness (SHA-256 persistence) | — |
| CVE-2026-39808 | FortiSandbox | Command injection (RCE) | Critical |
| CVE-2026-39813 | FortiSandbox | Authentication bypass | Critical |
| CVE-2026-35616 | FortiClient EMS | RCE / EKZ Stealer delivery | 9.1 |
The India and Asia Pacific Angle
Fortinet is the dominant firewall and NGFW vendor in India’s enterprise and mid-market segments. Thousands of FortiGate appliances protect NOC/SOC environments, branch networks, and data centres across BFSI, manufacturing, government, and IT/ITeS verticals — many running on FortiOS versions that pre-date the PBKDF2 migration introduced in the 7.2.11/7.4.8/7.6.1 branches.
Researchers specifically flagged Asia Pacific — alongside Latin America — as a primary target zone for FortiBleed activity. Indian enterprises face a compounding risk: many devices were deployed under multi-year managed contracts with conservative firmware update policies. Without a post-upgrade admin login, every one of those devices is potentially handing attackers a crackable SHA-256 hash on an otherwise “patched” appliance. This is not a theoretical risk — INC Ransom and Lynx have already activated FortiBleed access against real organisations. The question is whether your organisation’s credentials are in the next batch sold on a cybercrime forum.
This fits a pattern that has accelerated sharply in 2026: perimeter devices — the VPNs, firewalls, and remote access gateways that organisations trust most — are now the preferred ransomware entry point. We saw Qilin ransomware leverage a Check Point VPN zero-day just days ago. FortiBleed shows the same playbook applied at a far larger scale, without even needing a classic vulnerability.
What You Should Do Right Now: Sanjay Seth’s Recommended Playbook
With over 30 years of hands-on network security experience — including designing zero-trust architectures and managing Fortinet deployments across India — here is the incident response playbook I recommend for any organisation running FortiGate:
- Rotate all FortiGate admin and VPN credentials immediately. Assume your configuration hashes have been extracted and are in a cracking queue. Do not wait for your next maintenance window. Treat this as a Priority 1 incident.
- Force every administrator to log in after the credential reset. This is the step most teams overlook: resetting the password alone is not enough on older FortiOS builds. The actual login event triggers the SHA-256 to PBKDF2 conversion in FortiOS 7.2.11+, 7.4.8+, and 7.6.1+. Without that login event, the legacy hash format can persist.
- Upgrade FortiOS to a fixed release. Target FortiOS 7.2.11, 7.4.8, or 7.6.1 at minimum. Devices running older branches should be treated as compromised pending patching and re-credentialing.
- Enable MFA on all management and SSL VPN accounts — without exception. Even if credentials are cracked and valid, MFA breaks the authentication chain. Use FortiToken, a hardware token, or an integrated Identity Provider. On FortiOS 7.2.x/7.4.x, also enable the
login-lockout-upon-weaker-encryptionCLI setting. - Restrict management interface access to trusted IP ranges. FortiGate administration should never be internet-facing. Restrict access to RFC 1918 ranges only via local-in-policy or a dedicated out-of-band management VLAN with tight ACLs.
- Hunt for Golang sniffer implants. Audit FortiGate process lists via
diagnose sys process listand review all automation scripts and custom objects in your device configuration for unexpected entries. - Audit active SSL VPN sessions. Disable stale or unrecognised accounts. Review session logs for anomalous source IPs, unexpected geographies, and off-hours logins.
- Patch FortiSandbox and FortiClient EMS immediately against CVE-2026-39808, CVE-2026-39813, and CVE-2026-35616. These are being exploited as secondary vectors within the same campaign infrastructure.
For organisations running FortiGate SD-WAN across hub-and-spoke topologies, the risk is even more acute: a compromised SD-WAN hub firewall can cascade attacker access to every spoke site in your network. Treat your hub devices as the highest priority in your remediation sequence.
FortiBleed in Context: The Zero-Trust Lesson
FortiBleed is a masterclass in why implicit perimeter trust is an architectural liability. The very device your organisation relies on to enforce network security policy — the firewall — became the attacker’s most valuable asset. Zero-trust principles address this at every layer: no device, no account, and no network path is inherently trusted based solely on its role or position in the network.
Every administrative session should be authenticated with strong MFA, logged to a centralised SIEM, and subject to behavioural anomaly detection. Every privileged credential should be rotated on a defined schedule — not just “when there is a problem.” Configuration backups containing password hashes should be encrypted at rest and never stored on internet-accessible systems.
India’s DPDP Act and CERT-In’s 6-hour mandatory incident reporting requirement add a regulatory dimension: a compromised firewall that enables unauthorised access to customer or employee data creates immediate disclosure obligations. FortiBleed is not just a patching problem — it is a board-level risk that demands immediate executive attention.
For organisations looking to understand how Fortinet’s architecture fits into a robust zero-trust strategy — and why correct deployment and lifecycle management matter as much as the product selection itself — see my perspective on why Fortinet firewalls remain essential security infrastructure when deployed and maintained correctly.
Frequently Asked Questions
Does FortiBleed have a CVE number?
No — FortiBleed does not have a single assigned CVE because it exploits a credential storage design weakness rather than a traditional exploitable software vulnerability. The underlying issue is that FortiOS, on versions prior to 7.2.11/7.4.8/7.6.1, stored admin passwords as SHA-256 with salt; this hash is only converted to the stronger PBKDF2 scheme when the administrator logs in after a firmware upgrade. Multiple related CVEs are being exploited alongside FortiBleed: CVE-2026-39808 and CVE-2026-39813 (FortiSandbox), and CVE-2026-35616 (FortiClient EMS, CVSS 9.1).
Our FortiGate management port is not internet-facing — are we safe from FortiBleed?
Partially safer, but not immune. SSL VPN interfaces and API endpoint misconfigurations can expose device configuration data to external access even when the explicit HTTPS management port is not published on the internet. Additionally, if your device configuration has ever been backed up to an internet-accessible server, or if FortiCloud single sign-on was previously enabled, verify those paths did not expose credential hashes. The safest posture is to rotate all credentials regardless of your current exposure assessment — the cost of a credential rotation is far lower than the cost of a ransomware incident.
We run FortiOS 7.4.x — does upgrading to 7.4.8 fully resolve the issue?
Upgrading to 7.4.8 is necessary but not sufficient on its own. After upgrading, every administrator must perform a fresh login to trigger the cryptographic conversion from SHA-256 to PBKDF2 for their account. Without that post-upgrade login, the weak hash format persists even on a fully patched device. Enable the login-lockout-upon-weaker-encryption setting in FortiOS to automatically enforce this for any account that has not completed the hash conversion.
How active are INC Ransom and Lynx in the Indian market?
Both groups operate globally and have demonstrated interest in Asia Pacific targets. INC Ransom typically targets large enterprises across critical sectors including BFSI, healthcare, and government — all verticals with significant Fortinet deployments in India. Lynx is a newer affiliate-model ransomware operation that has been expanding aggressively into Asia Pacific. Researchers specifically called out APAC as a primary FortiBleed target zone; with India’s density of Fortinet deployments, any organisation with internet-facing FortiGate infrastructure should treat this as an active threat requiring immediate response — not a future planning item.
FortiBleed is a reminder that security is not a configuration you set once — it is a posture you maintain continuously. If you are unsure whether your Fortinet environment is exposed, or if you need help with a rapid FortiGate security audit, credential hygiene assessment, zero-trust segmentation review, or incident response engagement, reach out to Sanjay Seth for a security assessment. With three decades of hands-on experience and deep Fortinet expertise across India’s enterprise market, P J Networks can help you assess your exposure, remediate quickly, and build a security posture that does not depend on a single perimeter device never being compromised.