FortiBleed Is Real — and It's Not About Fortinet

This week two firms reported a credential-harvesting campaign — branded “FortiBleed” — said to affect tens of thousands of internet-facing Fortinet firewalls and VPNs. The core of it is real, and worth stating plainly: the credentials are genuine, many still work, and the activity is ongoing. By the reporting parties’ own accounts, no new vulnerability is involved. On June 18 the U.S. Cybersecurity and Infrastructure Security Agency issued an advisory on the campaign; its recommended response — reset credentials, enforce phishing-resistant MFA, lock down management interfaces — is worth acting on without delay, and is, tellingly, all credential hygiene and configuration rather than any product fix.

That last point is the story. If FortiBleed required no Fortinet-specific vulnerability, then the exposure it describes should not be Fortinet-specific either — it should appear, at comparable scale, across every vendor whose appliances sit on the public internet and authenticate with reusable credentials. We tested that directly against our own credential-exposure corpus, measuring the number of distinct organizations with remote-access portal credentials circulating in commodity infostealer data, using one fixed method applied identically to five major VPN platforms.

The result: Fortinet is not an outlier. Across five platforms the per-vendor counts range from about 1,700 to 3,600 distinct organizations, and Fortinet — the vendor in the headlines — sits fourth of five: three of the platforms we measured show higher exposure, one shows less. The variation tracks how much remote-access surface each platform has deployed over the years, not how secure it is. Separately, of the marquee “victims” named in the coverage, the four we sampled did not run the attack surface the campaign exploits at all. The dominant signal in the data is not vendor-specific weakness — it is the breadth of credential exposure across every major remote-access platform.

The campaign was first surfaced over the weekend by independent researcher Bob Diachenko, who found an exposed server holding working Fortinet credentials. It was then analyzed and published this week by Hudson Rock and SOCRadar, and the dataset was independently confirmed as legitimate by researcher Kevin Beaumont. As reported by TechCrunch on June 17, the operation uses automated scanning plus previously known passwords to reach exposed devices; it abuses no unknown vulnerability.

Fortinet’s position, provided to TechCrunch, is consistent with that: the company characterized the data as a reshare of credentials from prior incidents combined with brute-forcing, and stated it is “not related to any recent incident or advisory.” On the central technical question — whether this represents a new vulnerability in Fortinet’s products — the vendor and the reporting parties agree it does not.

These mechanisms have different technical causes but converge on the same outcome: valid credentials that authenticate to exposed remote-access infrastructure. That shared endpoint — a working credential, not a broken device — is what this analysis measures.

For reference, the figure has not settled across the reporting. As of June 17, Hudson Rock cited more than 73,000 unique Fortinet URLs and SOCRadar more than 30,000 devices — already different units (URLs are not devices are not organizations). By June 19, SecurityWeek had noted SOCRadar’s revision from 30,000 to 86,000, and CISA’s June 18 advisory cited approximately 74,000 devices. Across these accounts the number shifts with each retelling rather than converging on a value — which is the measurement problem this analysis sets out to avoid.

We measured a single quantity: the number of distinct registrable organizations whose remote-access portal credentials appear in our infostealer-log corpus. Not credentials, not URLs, not IP addresses, not devices — organizations, de-duplicated to the registrable domain. This is the only unit that supports a clean cross-vendor comparison, and it is deliberately the most conservative of the available counts.

Exposure is not compromise. A captured portal credential means an endpoint somewhere leaked a login to that surface — not that the device is breached or the organization is owned. The honest claim is narrow: credentials for these portals circulate in commodity stealer-log data. It applies equally to every vendor in the table.

And the unit keeps changing. By June 19 the same campaign was being counted in at least five different ways: roughly 1.16 billion credential attempts; more than 320,000 targeted devices; 74,000 to 86,644 compromised devices, depending on the source; 86,644 working credentials; and, where one firm matched the leaked data against its own telemetry, 845 affected organizations. Each counts something genuinely different, and a headline is free to reach for the largest. We count the most conservative of them — distinct organizations — for exactly that reason: it is the unit hardest to inflate.

The ordering is real, but it is not a security ranking. Citrix shows more exposure than Palo Alto in this corpus; that does not make Citrix “worse” or Palo Alto “safer.” A count like this rises with how many internet-facing portals a platform has in the field, and how long they have been there — deployment footprint and age, not the quality of the product behind them. Reading a league table of vendor security into these numbers would repeat the error this analysis exists to correct, simply pointed in a new direction.

The spread is shaped by deployment, not defect. Citrix NetScaler and the Cisco and Fortinet fleets are among the largest and oldest internet-facing remote-access footprints in the world; Palo Alto’s GlobalProtect is comparatively newer and more cloud-delivered. That the counts sort in roughly that order is the actual signal: exposure tracks the category and its footprint, not the vendor. The platform that drew the headline lands toward the lower end of the range — more exposed than one peer, less than three — which is unremarkable for any widely deployed platform, and not the profile of a singular outlier. A larger number for any vendor most plausibly means more surface deployed, and should never be read as a relative security judgment.

These are corpus-relative measurements. They describe representation within this credential-exposure corpus — not absolute estimates of global market exposure. We deliberately do not convert them into an “exposure rate” against deployed-device counts: reliable per-vendor deployment denominators do not exist, and dividing a firm number by a guessed one would manufacture exactly the kind of false precision this analysis is built to avoid. The raw, corpus-relative count is the honest figure, and we leave it as that.

Why the credential layer stays invisible

The reason this pattern persists — for every vendor — is that it lives in a layer the prevailing defensive model does not watch. Per-device, per-vulnerability scanning evaluates the appliance. It has nothing to say about a valid credential sitting in someone else’s database.

The same blind spot explains the shape of the headline. The industry watches artifacts — individual devices, individual vulnerabilities — and rarely measures the credential layer between them, where exposure accumulates continuously and across every vendor at once. Point a spotlight at one slice of that layer and attach a name, and a standing condition reads as a sudden, five-figure event — its scale a function of how much was never being counted, and, as the figures earlier showed, of how loosely the count is defined. Branding one vendor changes none of that: not where the exposure lives, and not how long it has lived there.

A note on standards, naming no one. Credible analysis states its unit, its method, and its limits, and reports the tests that failed to confirm its thesis. A figure that shifts severalfold within days — while blending devices, addresses, and credentials into a single number — is a headline, not a measurement. The difference is not tone; it is whether someone else can pick up the method and arrive at the same place.

What defenders should take from this is vendor-neutral, and the order matters — because against credentials harvested from infected endpoints, the controls are not equally effective. Every platform in this analysis already supports all of them; the exposure persists where they are not enforced, not where they are unavailable.

Multi-factor authentication, on every externally reachable gateway, is the control that defeats this dataset. A credential captured from an endpoint — however long, however recently rotated — does not authenticate without the second factor. It should be the floor on every device, not an option. Next, keep management interfaces off the public internet, which removes the place a stolen credential would be replayed. Then monitor the credential layer — whether your credentials are already circulating — because once a credential reaches a stealer log, every preventive control upstream has already been passed. Re-authenticate administrators after firmware updates so stored credential hashes are re-derived under current protections. Strong, screened credentials remain sound hygiene, but they are a single line item, not the fix: an infostealer captures a password in plaintext as it is typed, so length and rotation do nothing once the endpoint is compromised.

This is, in substance, what the U.S. Cybersecurity and Infrastructure Security Agency recommended. CISA’s June 18 advisory urges affected operators to reset credentials, store administrator hashes with PBKDF2, review authentication and domain-controller logs, enforce phishing-resistant MFA on every external gateway, and remove management access from the public internet — and it directs no one to patch a Fortinet product, because the activity it describes is credential exposure, not a software flaw. The official guidance and the measurement here point the same way: the fix lives in credential hygiene and configuration, which every platform in the table already supports.

The appliance being current is necessary. It was never sufficient — and that is true of every name in the table.

Portal-path fingerprints (host-anchored)

Each pattern is host-anchored (//[^/]+/) so the path must follow the host, not appear as a substring elsewhere in the URL. The Citrix pattern matches both the /index and /tmindex StoreFront variants; hosts on non-public namespaces (.corp, .intra, bare IPs) do not resolve to a registrable organization and are excluded, making the Citrix count conservative. SonicWall and Sophos are excluded for lack of a single distinctive portal path.

References