The mass password theft we warned you could not simply patch away has found a buyer. SOCRadar's Threat Research Unit now ties the FortiBleed campaign, an operation that quietly scraped more than 110 million logins from over 430,000 Fortinet firewalls, directly to two ransomware crews: INC and Lynx. This is not a new bug and there is still nothing to patch. It is the moment stolen access turned into encrypted networks. At least 12 ransomware deployments have already come out of it, and the same operators are holding a zero-day and a fresh target list for their next move.
FortiBleed, for anyone meeting it here first, is the name for the harvesting of credentials passing through compromised Fortinet FortiGate firewalls, the boxes that sit at the edge of a corporate network and broker who gets in. We covered it twice as it unfolded: first when it became clear this was stolen credentials rather than a software flaw, then when CISA's guidance made plain that a password reset would not lock the attacker out. Both points just got proven the hard way.
SOCRadar drew a straight line from harvest to ransom
The attribution came from a Windows server inside the FortiBleed infrastructure. On it, SOCRadar's researchers found browser sessions logged into the administration panels of both the INC and Lynx ransomware groups. In their reading, one individual with access to FortiBleed's back end was also working those gangs' negotiation platforms, the pages where victims are extorted. That is the first time mass FortiGate credential theft has been tied directly to ransomware deployment, rather than assumed.
The overlap is not only circumstantial. SOCRadar reports that victim data collected during FortiBleed later showed up on INC's public leak site, matching harvested organizations to named ransomware casualties. The operation itself is large: roughly 500 servers, more than 200 of them operational, run by a group of about 20 people with defined roles. A push through that stolen access scanned 11,250 FortiGate login portals across more than 150 countries, reached admin-level control on 409 of them, completed the full attack chain on 354, and ended in those 12 ransomware deployments that encrypted hundreds of endpoints.
Why rotating passwords was never going to be the whole answer
When we said a reset would not evict these attackers, this is the mechanism we meant. The traffic-sniffing implants keep running and keep collecting fresh credentials as staff log back in, so a one-time rotation just refills the well. SOCRadar puts those custom Golang sniffers on somewhere between 12,000 and 19,000 Fortinet devices, a count that fell to about 11,000 only after owners were notified and began cleaning up.
Worse, the crew planted persistence that survives a credential change entirely. Investigators found backdoor local accounts on compromised systems, several using the username adminin, a near-invisible typo-twin of a normal admin account. If your remediation stopped at rotating the leaked passwords, an account like that is still sitting on the box with its own way back in. This is the same trap that let INC ransomware thrive on unpatched edge devices without ever needing a zero-day: the initial access is cheap and the leftover footholds are what actually matter.
The front is widening: Nextcloud and Citrix are next
This is where the story stops being about Fortinet. SOCRadar says the FortiBleed operators are already using an undisclosed zero-day in Nextcloud, the self-hosted file-sync and collaboration platform, to expand their access. No CVE identifier or technical write-up exists yet, and SOCRadar says it is coordinating with the vendor, so the only defensive move today is heightened monitoring of Nextcloud authentication and admin activity rather than a patch.
The same infrastructure also held a hit list naming roughly 29,000 Citrix-linked addresses across 37 domains, a strong signal that NetScaler gateways are on the roadmap. That lands the same week Citrix appliances came under fresh pressure from a CitrixBleed-style memory-overread flaw exploited within a day of disclosure. A crew already sitting on hundreds of thousands of Fortinet footholds, an unpublished Nextcloud bug, and a Citrix hit list is not winding down. It is diversifying its supply of victims.
One thread worth keeping separate: eSentire reported a distinct campaign exploiting CVE-2026-35616, a critical flaw in Fortinet FortiClient EMS rated 9.1, to deploy a stealer it calls EKZ against an energy-sector target. That one is a patchable Fortinet product bug and is not part of FortiBleed. It is a useful reminder that Fortinet access is the hot commodity right now, being pursued through more than one door at once.
Hunt for the leftover access, not just the leaked password
Treat any FortiGate that was internet-facing during this campaign as a device that already gave up its secrets. The work is eviction and containment, not a routine reset.
-
Rotate everything that touched the firewall, then rotate it again. VPN logins, admin accounts, and any local credentials that authenticated through an affected FortiGate should be reissued, with multi-factor authentication enforced so a single stolen password stops being enough.
-
Hunt for persistence before you call it clean. Look for local admin accounts you did not create, including the
admininusername SOCRadar flagged, and review firewall and directory logs for admin logins from unfamiliar locations. A cleared credential means nothing if a backdoor account remains. -
Watch the widening front. If you run Nextcloud, raise monitoring on authentication and administrative actions now, since there is no patch for the zero-day yet. If you run Citrix NetScaler, confirm you are current on the recent fixes and check your authentication logs for the anomalous logins that precede these intrusions.
-
Check whether you are already a name. Cross-reference your organization against the INC leak site. If FortiBleed harvested you and the access was resold, being listed may be your earliest warning.
The lesson of FortiBleed keeps sharpening: the breach was never the firewall bug, because there was not one. It was the assumption that a password, once changed, was safe again. INC and Lynx just turned that assumption into ransom notes.