FortiBleed: 73,000+ FortiGate Credentials in Circulation, What the Leak Reveals About SSL VPN Appliances

Validated administrator and VPN credentials for more than 73,000 internet-facing FortiGate firewalls have been in circulation since mid-June 2026, and according to Bitsight, researchers estimate that approximately 50 percent of all internet-reachable FortiGate devices may be affected. The campaign known as FortiBleed spans 194 countries; Heise counted around 120 devices with German domain indicators, including systems at Telekom and Mercedes-Benz. There are two readings of the cause: Fortinet points to reused credentials and brute force, while Bitsight additionally describes an uncomfortable technical detail in which admin passwords remain stored as weak SHA-256 hashes after FortiOS upgrades until the administrator logs in again, and a 45-GPU cluster systematically cracked those hashes. This article puts the facts in order, lists the immediate actions recommended by Fortinet and the Baden-Württemberg State Office for the Protection of the Constitution, and draws the structural lesson: why a perimeter appliance with an exposed VPN portal becomes a concentration risk, and how an identity-based mesh distributes that risk differently.

FortiBleed in Numbers: What Became Known on 18 June 2026

On 18 June 2026, the security company Bitsight published its report on the campaign known as FortiBleed: a dataset with administrator and VPN credentials for more than 73,000 internet-facing FortiGate firewalls is in circulation.[1] Bitsight phrases this with a double hedge: researchers estimate that approximately 50 percent of all internet-reachable FortiGate devices across 194 countries "may be affected".[1] According to BleepingComputer, the dataset was discovered by security researcher Bob Diachenko, who came across a server containing what appeared to be valid Fortinet VPN credentials.[2]

The authenticity of part of the data was confirmed, also according to BleepingComputer, by security researcher Kevin Beaumont: "The data is legit. It is around 75k devices. Almost all are still online, and Fortinet devices. It appears to be recent data."[2] Hudson Rock contributed a statistical analysis of the victims, for example by sector; that is not an independent authenticity confirmation.[2] The key figures at a glance:

For the DACH region, this incident is not a distant headline: Heise documented the roughly 120 devices with German domain indicators, naming Telekom and Mercedes-Benz among the affected organizations.[3] On 25 June 2026, the Baden-Württemberg State Office for the Protection of the Constitution (LfV BW) explicitly warned German companies, stating that more than 70,000 devices are affected worldwide, including large German enterprises. The agency names no reliable attribution, but points to indications of a Russian-speaking group.[5]

How the Attackers Obtained the Credentials

There are two narratives about the origin of the data, and they do not fully exclude each other. Both deserve a fair presentation.

Fortinet's Reading: Old Credentials Plus Brute Force

On 19 June 2026, Fortinet stated in its PSIRT blog: "This is not a new Fortinet vulnerability, and this activity is not related to any recent incident or advisory."[4] In this reading, the attackers reused credentials from earlier incidents and combined them with massive brute-forcing against devices with weak passwords and no multi-factor authentication.[4] The blog references the advisories FG-IR-25-647 and FG-IR-26-060, recommends upgrading to FortiOS versions with PBKDF2 password hashing (7.4, 7.6 and 8.0) and removing legacy password settings, and Fortinet says it is proactively contacting affected customers.[4] Part of the telemetry fits this reading: BleepingComputer reports 1.16 billion login attempts against 320,777 FortiGate targets.[2]

Bitsight's Finding: SHA-256 Hashes After Upgrades and a 45-GPU Cluster

Bitsight describes a second path that starts with the devices' configuration data. The report names a FortiOS behavior: when devices are upgraded from older versions, administrator passwords remain stored as weak SHA-256 hashes until the administrator manually logs in after the upgrade.[1] According to Bitsight, attackers systematically broke exactly these hashes with a 45-GPU offline cracking infrastructure, yielding validated working credentials for tens of thousands of devices.[1] BleepingComputer adds that the GPU cluster was managed through the Hashtopolis platform.[2]

What Remains Open

How the configuration data was obtained has not been conclusively documented in public. According to BleepingComputer, Kevin Beaumont points out that the affected IP addresses differ markedly from those in the 2025 Belsen leak; simply republishing old datasets therefore does not explain FortiBleed, as the dataset is separate, more recent and larger.[2] Both readings can coexist: credential recycling and brute force explain part of the access, cracked hashes from configuration data another. For those affected, the distinction is secondary anyway, because the consequence is identical: rotate, patch, harden.

Not the First Incident: Belsen, Symlink Backdoor, 2FA Bypass

FortiBleed hits an installed base that already had to digest several incidents in the preceding 18 months. The chronology:

Two points in this chronology deserve particular attention. First, the 2FA bypass: multi-factor authentication is the standard recommendation after every credential leak, and it is the right one. CVE-2020-12812, however, shows that MFA could be bypassed on the appliance itself as long as the device was unpatched, a vulnerability from 2020 that was actively exploited at the end of 2025.[9] MFA therefore only protects on a patched device. Second, the July patch day: four weeks after FortiBleed, it was the SSL VPN of all components that produced another advisory.[12] That is not an accusation against Fortinet, but an indication of how much attack surface an exposed perimeter appliance permanently offers. That this pattern is not tied to one vendor is shown in Sophos VPN alternative 2026 and Cisco AnyConnect alternative 2026.

Immediate Actions for FortiGate Operators

Fortinet and the Baden-Württemberg State Office for the Protection of the Constitution essentially recommend the same steps.[4][5] If you operate FortiGate devices with SSL VPN or a reachable admin interface, work through this list completely:

1. Review access and remove foreign accounts: Check admin and VPN accounts for unknown entries and remove foreign accounts.[5] Additionally, terminate existing sessions so that rotated credentials take effect immediately.
2. Rotate all admin and VPN credentials: In case of doubt, treat devices as compromised. Fortinet is proactively contacting affected customers; you do not need to wait for that.[4]
3. Upgrade to a PBKDF2-capable FortiOS version: FortiOS 7.4, 7.6 and 8.0 support the stronger password hashing; Fortinet additionally recommends removing legacy password settings.[4]
4. Log in again after the upgrade and reset passwords: According to Bitsight, old SHA-256 hashes remain stored after the upgrade until the administrator manually logs in again. An update alone does not remove the weak hashes.[1]
5. Enforce MFA and verify patch status: Enforce MFA for all admin and VPN access and make sure the 2FA bypass CVE-2020-12812 is patched on your devices.[5][9]
6. Take the management interface off the internet: Administrative access belongs in an internal network or behind a dedicated access path, not on a public IP.[5]
7. Check logs and configurations for third-party access: Look for unusual logins, configuration changes and new accounts, and preserve evidence before cleaning up.

The Structural Problem: Why an Appliance Becomes a Concentration Risk

The more interesting question is not what Fortinet did wrong, but why a single dataset can hit tens of thousands of organizations at once in the first place. The answer lies in the architecture of the perimeter appliance: one device combines firewall, VPN gateway, admin interface and credential store on a box reachable from the internet. The configuration file thus becomes a master key. Whoever obtains it, whether via CVE, backdoor or leak, gets password hashes, certificates, firewall rules and the network topology all at once.

Add the scale effect of the monoculture: tens of thousands of FortiGate devices sit directly on the internet with identical software and identical failure modes. One dataset, one toolkit, and according to Bitsight the attack scales to more than 73,000 devices across 194 countries.[1] That is the definition of a concentration risk. Belsen (2025), the symlink backdoor (2025) and FortiBleed (2026) are three manifestations of the same structural problem, and the incidents at Sophos, Cisco and other vendors show it is not specific to Fortinet. To be fair: Fortinet analyzed the situation within a day, pointed to versions with stronger password hashing and proactively contacted affected customers.[4]

The Counter-Model: Identity Instead of Perimeter

An identity-based WireGuard mesh like NetBird organizes remote access fundamentally differently. Devices establish direct, encrypted connections from peer to peer; there is no publicly listening VPN login portal per site, and the peers require no inbound open ports. Authentication happens against your identity provider via SSO, not against local accounts on a gateway. VPN password hashes in device configurations, the central artifact of FortiBleed, do not exist in this model. Access is granted per identity and policy rather than per network segment, and offboarding runs through the IdP instead of manually maintained device accounts.

Honesty is part of the picture: a mesh shifts the risk, it does not eliminate it. NetBird is software too, has a management plane and needs consistent patching, and the identity provider becomes a critical dependency. The difference lies in the attack surface, because there is no permanently exposed login portal that makes every new SSL VPN vulnerability immediately exploitable, and in a clear answer to the question of who actually patches.

Where birdhost Comes In

By everything that has been documented, FortiBleed primarily hit organizations where upgrades, password rotation and MFA were left undone. Exactly this operational burden is what birdhost shifts to the provider: your dedicated NetBird instance is updated, patched and monitored around the clock by birdhost; client updates on the endpoints remain your task, which is part of the honest division of labor. Every customer receives their own instance; there is no credential pool shared across customers. Hosting is available in Germany in ISO 27001 and BSI C5 certified data centers (certifications held by the respective data center operator), with 8 regions to choose from in total.

Pricing is predictable: Startup from €99.90/month, Business from €199.90/month (both Germany region, plus VAT), Enterprise on request. All plans include unlimited users and devices and can be cancelled monthly; relay traffic is included at 2 TB (Startup) and 4 TB (Business), then €1/TB. You can test for 7 days; a credit card is required to start. This article deliberately does not repeat the full product comparison of FortiGate/FortiClient versus NetBird including the cost calculation: you will find it in Fortinet VPN alternative 2026.

Transparency: birdhost is not an official NetBird product and is not affiliated with NetBird GmbH. Fortinet, FortiGate and FortiOS are trademarks of their respective owners.

Decision Guide: Harden or Change the Architecture

The hardened FortiGate is enough if:

• the FortiGate is primarily a firewall (segmentation, IDS/IPS, web filtering) and VPN remains a secondary function with few users,
• the admin interface is never reachable from the internet and MFA is enforced everywhere,
• a PBKDF2-capable FortiOS version is running and credentials were rotated after FortiBleed,
• an internal team or a partner demonstrably patches the device in a timely manner.

The architecture change to an identity-based mesh is worthwhile if:

• remote access is the main purpose, with many users, sites or external contractors,
• nobody reliably has capacity for appliance patching and password rotation, which is exactly the operational profile FortiBleed hit,
• offboarding and access management should run automatically via SSO and your IdP, identity instead of network segment,
• GDPR or NIS2 driven requirements for EU hosting and clear patch responsibility exist.

The honest addition: if you want full control and can operate it yourself, use NetBird self-hosted. The software is open source and works without birdhost; the managed approach pays off where the operational burden is the problem.

Compliance Context: GDPR and NIS2

Compromised VPN and admin credentials can trigger notifiable data protection incidents under Art. 33 GDPR if personal data is affected. For entities in scope of NIS2, incidents like FortiBleed are additionally a matter of risk management and reporting obligations; the selection and hardening of the remote access solution is part of the required measures, see NIS2 and VPN: network security requirements for details. Operating the VPN control plane in the EU additionally reduces US cloud dependencies; the analysis is in GDPR-compliant VPN: the US cloud compliance risk. This article is not legal advice; involve your data protection or legal counsel for specific questions.

Conclusion: Rotating Is Mandatory, the Architecture Question Is the Next Step

FortiBleed is not evidence of a Fortinet failure, and panic is not a measure. The vendor analyzed quickly, gave clear recommendations and contacted affected customers. But the incident shows what a single dataset can do when tens of thousands of identical, exposed devices carry the same weak password hashes: credentials for more than 73,000 firewalls across 194 countries, validated and mostly still online. In the short term, every FortiGate operator should: terminate sessions, rotate credentials, upgrade to a PBKDF2-capable version, log in again, enforce MFA, take the management interface off the internet. In the medium term, the architecture question is worth asking: a remote access model without an exposed login portal and without password hashes in device configurations takes away the target of the next FortiBleed, and in birdhost's managed model it also removes the operational burden on which hardening most often fails in practice.

Sources

• [[1]] Bitsight: "Major Security Event: Fortinet VPN Credentials and Configuration Data Exposed for 73,000 Devices" (18 June 2026)
• [[2]] BleepingComputer: "FortiBleed leak exposes Fortinet VPN credentials for 73,000 devices" (18 June 2026)
• [[3]] Heise: "Massiver Angriff auf Fortinet-Firewalls: 74.000 Geräte von FortiBleed betroffen" (17 June 2026, updated)
• [[4]] Fortinet PSIRT blog: "Analysis of Reported Credential Compromise of FortiGate Devices" (19 June 2026)
• [[5]] Baden-Württemberg State Office for the Protection of the Constitution: warning on the FortiBleed attack campaign (25 June 2026)
• [[6]] BleepingComputer: "Hackers leak configs and VPN credentials for 15,000 FortiGate devices" (15 January 2025)
• [[7]] Fortinet PSIRT blog: "Analysis of Threat Actor Data Posting" (16 January 2025)
• [[8]] FortiGuard PSIRT FG-IR-25-647: CVE-2025-59718/59719, CVSS 9.1, exploited in the wild (9 December 2025)
• [[9]] The Hacker News: Fortinet warns of active exploitation of CVE-2020-12812 (25 December 2025)
• [[10]] FortiGuard PSIRT FG-IR-26-060: CVE-2026-24858, CVSS 9.4, exploited in the wild (27 January 2026)
• [[11]] BSI: cybersecurity warning on CVE-2026-24858, version 1.2 (29 January 2026)
• [[12]] FortiGuard PSIRT FG-IR-26-150: CVE-2026-23573, reflected XSS in the SSL VPN, CVSS 6.1 (14 July 2026)
• [[13]] NVD: CVE-2026-23573