FortiBleed: 73.000+ FortiGate-Zugänge im Umlauf, was der Leak über SSL-VPN-Appliances verrät

Validierte Administrator- und VPN-Zugangsdaten für mehr als 73.000 internet-erreichbare FortiGate-Firewalls sind seit Mitte Juni 2026 im Umlauf, und laut Bitsight schätzen Researcher, dass rund 50 Prozent aller aus dem Internet erreichbaren FortiGate-Geräte betroffen sein könnten. Die unter dem Namen FortiBleed bekannte Kampagne erstreckt sich über 194 Länder; Heise zählte rund 120 Geräte mit deutschen Domain-Indikatoren, darunter Systeme bei Telekom und Mercedes-Benz. Zur Ursache gibt es zwei Lesarten: Fortinet spricht von wiederverwendeten Zugangsdaten und Brute Force, Bitsight beschreibt zusätzlich eine unbequeme technische Eigenheit, bei der Admin-Passwörter nach FortiOS-Upgrades als schwache SHA-256-Hashes gespeichert bleiben, bis sich der Administrator erneut anmeldet, und ein 45-GPU-Cluster diese Hashes systematisch knackte. Dieser Beitrag ordnet die Faktenlage ein, listet die Sofortmaßnahmen von Fortinet und dem Verfassungsschutz Baden-Württemberg auf und zieht die strukturelle Lehre: warum eine Perimeter-Appliance mit exponiertem VPN-Portal zum Klumpenrisiko wird und wie ein identitätsbasiertes Mesh dieses Risiko anders verteilt.

FortiBleed in Zahlen: Was am 18. Juni 2026 bekannt wurde

Am 18. Juni 2026 veröffentlichte das Sicherheitsunternehmen Bitsight seinen Report zu der unter dem Namen FortiBleed bekannten Kampagne: Im Umlauf ist ein Datensatz mit Administrator- und VPN-Zugangsdaten für mehr als 73.000 internet-erreichbare FortiGate-Firewalls.[1] Bitsight formuliert dabei doppelt vorsichtig: Researcher schätzen demnach, dass rund 50 Prozent aller aus dem Internet erreichbaren FortiGate-Geräte in 194 Ländern betroffen sein könnten ("may be affected").[1] Entdeckt hatte den Datensatz laut BleepingComputer der Sicherheitsforscher Bob Diachenko, der auf einen Server mit augenscheinlich gültigen Fortinet-VPN-Zugangsdaten stieß.[2]

Die Echtheit eines Teils der Daten bestätigte, ebenfalls laut BleepingComputer, der Sicherheitsforscher 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 steuerte eine statistische Auswertung der Betroffenen bei, etwa nach Branchen; eine eigene Echtheitsbestätigung ist das nicht.[2] Die wichtigsten Kennzahlen im Überblick:

Für den DACH-Raum ist der Vorfall damit keine ferne Meldung: Heise dokumentierte die rund 120 Geräte mit deutschen Domain-Indikatoren namentlich bis hin zu Telekom und Mercedes-Benz.[3] Am 25. Juni 2026 warnte zudem der Verfassungsschutz Baden-Württemberg deutsche Unternehmen ausdrücklich: Weltweit seien "über 70.000 Geräte betroffen", auch große deutsche Unternehmen. Eine belastbare Attribution nennt die Behörde nicht, es gebe jedoch Hinweise auf eine russischsprachige Gruppierung.[5]

Wie die Angreifer an die Zugangsdaten kamen

Zur Herkunft der Daten gibt es zwei Erzählungen, die sich nicht vollständig ausschließen. Beide verdienen eine faire Darstellung.

Fortinets Lesart: alte Zugangsdaten plus Brute Force

Fortinet stellte am 19. Juni 2026 im PSIRT-Blog klar: "This is not a new Fortinet vulnerability, and this activity is not related to any recent incident or advisory."[4] Nach dieser Lesart verwerteten die Angreifer Zugangsdaten aus früheren Vorfällen und kombinierten sie mit massivem Brute-Forcing gegen Geräte mit schwachen Passwörtern und ohne Multi-Faktor-Authentifizierung.[4] Der Blog verweist auf die Advisories FG-IR-25-647 und FG-IR-26-060, empfiehlt das Upgrade auf FortiOS-Versionen mit PBKDF2-Passwort-Hashing (7.4, 7.6 und 8.0) samt Entfernen von Legacy-Password-Settings, und Fortinet kontaktiert betroffene Kunden nach eigenen Angaben proaktiv.[4] Ein Teil der Telemetrie passt zu dieser Lesart: BleepingComputer berichtet über 1,16 Milliarden Anmeldeversuche gegen 320.777 FortiGate-Ziele.[2]

Bitsights Befund: SHA-256-Hashes nach Upgrades und ein 45-GPU-Cluster

Bitsight beschreibt einen zweiten Pfad, der bei den Konfigurationsdaten der Geräte ansetzt. Der Report benennt eine FortiOS-Eigenheit: Werden Geräte von älteren Versionen aktualisiert, bleiben Administrator-Passwörter als schwache SHA-256-Hashes gespeichert, bis sich der Administrator nach dem Upgrade manuell anmeldet.[1] Genau diese Hashes brachen die Angreifer laut Bitsight mit einer 45-GPU-Offline-Infrastruktur systematisch und gewannen so validierte, funktionierende Zugangsdaten für zehntausende Geräte.[1] BleepingComputer ergänzt, dass der GPU-Cluster über die Plattform Hashtopolis verwaltet wurde.[2]

Was offen bleibt

Wie die Konfigurationsdaten beschafft wurden, ist öffentlich nicht abschließend dokumentiert. Kevin Beaumont weist laut BleepingComputer darauf hin, dass sich die betroffenen IP-Adressen deutlich von denen des Belsen-Leaks aus dem Jahr 2025 unterscheiden; ein bloßes Wiederveröffentlichen alter Datensätze erklärt FortiBleed demnach nicht, der Datensatz ist separat, aktueller und größer.[2] Beide Lesarten können nebeneinander bestehen: Credential-Recycling und Brute Force erklären einen Teil der Zugriffe, geknackte Hashes aus Konfigurationsdaten einen anderen. Für Betroffene ist die Unterscheidung ohnehin zweitrangig, die Konsequenz ist identisch: rotieren, patchen, härten.

Nicht der erste Vorfall: Belsen, Symlink-Backdoor, 2FA-Bypass

FortiBleed trifft eine Installationsbasis, die in den 18 Monaten zuvor bereits mehrere Vorfälle verarbeiten musste. Die Chronologie:

Zwei Punkte dieser Chronologie verdienen besondere Aufmerksamkeit. Erstens der 2FA-Bypass: Multi-Faktor-Authentifizierung ist die Standard-Empfehlung nach jedem Credential-Leak, und sie ist richtig. CVE-2020-12812 zeigt aber, dass MFA auf der Appliance selbst umgangen werden konnte, solange das Gerät ungepatcht war, eine Schwachstelle aus dem Jahr 2020, die Ende 2025 aktiv ausgenutzt wurde.[9] MFA schützt also nur auf einem gepatchten Gerät. Zweitens der Juli-Patchday: Vier Wochen nach FortiBleed produzierte ausgerechnet das SSL-VPN erneut ein Advisory.[12] Das ist kein Vorwurf an Fortinet, sondern ein Hinweis darauf, wie viel Angriffsfläche eine exponierte Perimeter-Appliance dauerhaft bietet. Dass dieses Muster nicht an einem Hersteller hängt, zeigen Sophos VPN Alternative 2026 und Cisco AnyConnect Alternative 2026.

Sofortmaßnahmen für FortiGate-Betreiber

Fortinet und der Verfassungsschutz Baden-Württemberg empfehlen im Kern dieselben Schritte.[4][5] Wenn Sie FortiGate-Geräte mit SSL-VPN oder erreichbarem Admin-Interface betreiben, arbeiten Sie diese Liste vollständig ab:

1. Zugänge prüfen und fremde Konten entfernen: Kontrollieren Sie Admin- und VPN-Konten auf unbekannte Einträge und entfernen Sie fremde Konten.[5] Beenden Sie zusätzlich bestehende Sessions, damit rotierte Zugangsdaten sofort greifen.
2. Alle Admin- und VPN-Credentials rotieren: Behandeln Sie Geräte im Zweifel wie kompromittiert. Fortinet kontaktiert betroffene Kunden proaktiv; warten müssen Sie darauf nicht.[4]
3. Auf eine PBKDF2-fähige FortiOS-Version aktualisieren: FortiOS 7.4, 7.6 und 8.0 unterstützen das stärkere Passwort-Hashing; Fortinet empfiehlt zusätzlich, Legacy-Password-Settings zu entfernen.[4]
4. Nach dem Upgrade neu anmelden und Passwörter neu setzen: Laut Bitsight bleiben alte SHA-256-Hashes nach dem Upgrade gespeichert, bis sich der Administrator manuell neu anmeldet. Ein Update allein beseitigt die schwachen Hashes nicht.[1]
5. MFA erzwingen und Patch-Stand prüfen: Erzwingen Sie MFA für alle Admin- und VPN-Zugänge und stellen Sie sicher, dass der 2FA-Bypass CVE-2020-12812 auf Ihren Geräten gepatcht ist.[5][9]
6. Management-Interface aus dem Internet nehmen: Administrationszugänge gehören in ein internes Netz oder hinter einen dedizierten Zugriffspfad, nicht auf eine öffentliche IP.[5]
7. Logs und Konfigurationen auf Fremdzugriff prüfen: Suchen Sie nach ungewöhnlichen Anmeldungen, Konfigurationsänderungen und neuen Konten, und sichern Sie Beweise, bevor Sie aufräumen.

Das strukturelle Problem: Warum eine Appliance zum Klumpenrisiko wird

Die interessantere Frage lautet nicht, was Fortinet falsch gemacht hat, sondern warum ein einzelner Datensatz überhaupt zehntausende Organisationen gleichzeitig treffen kann. Die Antwort liegt in der Architektur der Perimeter-Appliance: Ein Gerät vereint Firewall, VPN-Gateway, Admin-Interface und Credential-Speicher auf einer aus dem Internet erreichbaren Box. Die Konfigurationsdatei wird damit zum Generalschlüssel. Wer sie bekommt, ob per CVE, Backdoor oder Leak, erhält Passwort-Hashes, Zertifikate, Firewall-Regeln und die Netz-Topologie gleich mit.

Dazu kommt der Skaleneffekt der Monokultur: FortiGate-Geräte stehen zu zehntausenden direkt im Internet, mit identischer Software und identischen Fehlerbildern. Ein Datensatz, ein Werkzeugkasten, und der Angriff skaliert laut Bitsight auf mehr als 73.000 Geräte in 194 Ländern.[1] Das ist die Definition von Klumpenrisiko. Belsen (2025), die Symlink-Backdoor (2025) und FortiBleed (2026) sind drei Ausprägungen desselben strukturellen Problems, und die Vorfälle bei Sophos, Cisco und anderen Herstellern zeigen, dass es kein Fortinet-spezifisches ist. Fair bleibt festzuhalten: Fortinet hat binnen eines Tages analysiert, auf Versionen mit stärkerem Passwort-Hashing verwiesen und Betroffene proaktiv kontaktiert.[4]

Das Gegenmodell: Identität statt Perimeter

Ein identitätsbasiertes WireGuard-Mesh wie NetBird organisiert Remote-Zugriff grundlegend anders. Die Geräte bauen direkte, verschlüsselte Verbindungen von Peer zu Peer auf; es gibt kein öffentlich lauschendes VPN-Login-Portal pro Standort, und die Peers benötigen keine eingehend offenen Ports. Authentifiziert wird gegen Ihren Identity Provider per SSO, nicht gegen lokale Konten auf einem Gateway. VPN-Passwort-Hashes in Geräte-Konfigurationen, das zentrale Artefakt von FortiBleed, existieren in diesem Modell nicht. Zugriff wird pro Identität und Richtlinie erteilt statt pro Netzsegment, und Offboarding läuft über den IdP statt über manuell gepflegte Gerätekonten.

Zur Ehrlichkeit gehört: Ein Mesh verschiebt das Risiko, es beseitigt es nicht. Auch NetBird ist Software, hat eine Management-Ebene und braucht konsequentes Patching, und der Identity Provider wird zur kritischen Abhängigkeit. Der Unterschied liegt in der Angriffsfläche, denn es gibt kein permanent exponiertes Login-Portal, das jede neue SSL-VPN-Schwachstelle sofort angreifbar macht, und in der klaren Antwort auf die Frage, wer eigentlich patcht.

Wo birdhost ansetzt

FortiBleed traf nach allem, was dokumentiert ist, vor allem Organisationen, bei denen Upgrades, Passwort-Rotation und MFA liegen blieben. Genau diese Betriebslast verlagert birdhost auf den Anbieter: Ihre dedizierte NetBird-Instanz wird von birdhost aktualisiert, gepatcht und rund um die Uhr überwacht; Client-Updates auf den Endgeräten bleiben Ihre Aufgabe, das gehört zur ehrlichen Arbeitsteilung dazu. Jeder Kunde erhält eine eigene Instanz, einen über Kunden hinweg geteilten Credential-Pool gibt es nicht. Gehostet wird auf Wunsch in Deutschland in ISO-27001- und BSI-C5-zertifizierten Rechenzentren (Zertifizierungen des jeweiligen Rechenzentrumsbetreibers), insgesamt stehen 8 Regionen zur Wahl.

Die Preise sind planbar: Startup ab 99,90 €/Monat, Business ab 199,90 €/Monat (jeweils Region Deutschland, zzgl. MwSt.), Enterprise auf Anfrage. Alle Pläne enthalten unbegrenzte Nutzer und Geräte und sind monatlich kündbar; Relay-Traffic ist mit 2 TB (Startup) beziehungsweise 4 TB (Business) inklusive, danach 1 €/TB. Testen können Sie 7 Tage; für den Start ist eine Kreditkarte erforderlich. Den vollständigen Produktvergleich FortiGate/FortiClient gegen NetBird samt Kostenrechnung wiederholt dieser Beitrag bewusst nicht: Sie finden ihn in Fortinet VPN Alternative 2026.

Transparenz: birdhost ist kein offizielles NetBird-Produkt und steht in keiner Verbindung zur NetBird GmbH. Fortinet, FortiGate und FortiOS sind Marken ihrer jeweiligen Inhaber.

Entscheidungshilfe: Härten oder Architektur wechseln

Die gehärtete FortiGate reicht, wenn:

• die FortiGate primär Firewall ist (Segmentierung, IDS/IPS, Web-Filtering) und VPN eine Nebenfunktion mit wenigen Nutzern bleibt,
• das Admin-Interface nie aus dem Internet erreichbar ist und MFA überall erzwungen wird,
• eine PBKDF2-fähige FortiOS-Version läuft und die Credentials nach FortiBleed rotiert wurden,
• ein internes Team oder ein Partner das Gerät nachweislich zeitnah patcht.

Der Architekturwechsel zum identitätsbasierten Mesh lohnt, wenn:

• Remote Access der Hauptzweck ist, mit vielen Nutzern, Standorten oder externen Dienstleistern,
• niemand verlässlich Kapazität für Appliance-Patching und Passwort-Rotation hat, also genau das Betriebsprofil vorliegt, das FortiBleed traf,
• Offboarding und Zugriffsverwaltung automatisch über SSO und IdP laufen sollen, Identität statt Netzsegment,
• DSGVO- oder NIS2-getriebene Anforderungen an EU-Hosting und klare Patch-Verantwortung bestehen.

Der ehrliche Zusatz: Wer volle Kontrolle will und selbst betreiben kann, nutzt NetBird Self-Hosted. Die Software ist Open Source und funktioniert auch ohne birdhost; der Managed-Ansatz lohnt dort, wo die Betriebslast das Problem ist.

Compliance-Einordnung: DSGVO und NIS2

Kompromittierte VPN- und Admin-Zugänge können meldepflichtige Datenschutzvorfälle nach Art. 33 DSGVO auslösen, wenn personenbezogene Daten betroffen sind. Für Einrichtungen im NIS2-Anwendungsbereich sind Vorfälle wie FortiBleed zudem ein Thema für Risikomanagement und Meldepflichten; die Auswahl und Härtung der Remote-Access-Lösung gehört zu den geforderten Maßnahmen, Details in NIS2 und VPN: Anforderungen an die Netzwerksicherheit. Wer die VPN-Control-Plane in der EU betreibt, reduziert zusätzlich US-Cloud-Abhängigkeiten; die Analyse dazu steht in DSGVO-konformes VPN: das US-Cloud-Compliance-Risiko. Dieser Beitrag ist kein Rechtsrat; beziehen Sie bei konkreten Fragen Ihre Datenschutz- oder Rechtsberatung ein.

Fazit: Rotieren ist Pflicht, die Architekturfrage ist die Kür

FortiBleed ist kein Beleg für ein Fortinet-Versagen, und Panik ist keine Maßnahme. Der Hersteller hat schnell analysiert, klare Empfehlungen gegeben und Betroffene kontaktiert. Der Vorfall zeigt aber, was ein einzelner Datensatz anrichten kann, wenn zehntausende identische, exponierte Geräte dieselben schwachen Passwort-Hashes tragen: Zugangsdaten für mehr als 73.000 Firewalls in 194 Ländern, validiert und größtenteils noch online. Kurzfristig gilt für jeden FortiGate-Betreiber: Sessions beenden, Credentials rotieren, auf eine PBKDF2-fähige Version aktualisieren, neu anmelden, MFA erzwingen, Management-Interface vom Internet trennen. Mittelfristig lohnt die Architekturfrage: Ein Remote-Access-Modell ohne exponiertes Login-Portal und ohne Passwort-Hashes in Gerätekonfigurationen nimmt dem nächsten FortiBleed das Ziel, und im Managed-Modell von birdhost auch die Betriebslast, an der die Härtung in der Praxis am häufigsten scheitert.

Quellen

• [[1]] Bitsight: "Major Security Event: Fortinet VPN Credentials and Configuration Data Exposed for 73,000 Devices" (18.06.2026)
• [[2]] BleepingComputer: "FortiBleed leak exposes Fortinet VPN credentials for 73,000 devices" (18.06.2026)
• [[3]] Heise: "Massiver Angriff auf Fortinet-Firewalls: 74.000 Geräte von FortiBleed betroffen" (17.06.2026, aktualisiert)
• [[4]] Fortinet PSIRT-Blog: "Analysis of Reported Credential Compromise of FortiGate Devices" (19.06.2026)
• [[5]] Verfassungsschutz Baden-Württemberg: Warnung zur FortiBleed-Angriffskampagne (25.06.2026)
• [[6]] BleepingComputer: "Hackers leak configs and VPN credentials for 15,000 FortiGate devices" (15.01.2025)
• [[7]] Fortinet PSIRT-Blog: "Analysis of Threat Actor Data Posting" (16.01.2025)
• [[8]] FortiGuard PSIRT FG-IR-25-647: CVE-2025-59718/59719, CVSS 9.1, aktiv ausgenutzt (09.12.2025)
• [[9]] The Hacker News: Fortinet warnt vor aktiver Ausnutzung von CVE-2020-12812 (25.12.2025)
• [[10]] FortiGuard PSIRT FG-IR-26-060: CVE-2026-24858, CVSS 9.4, aktiv ausgenutzt (27.01.2026)
• [[11]] BSI: Cybersicherheitswarnung zu CVE-2026-24858, Version 1.2 (29.01.2026)
• [[12]] FortiGuard PSIRT FG-IR-26-150: CVE-2026-23573, Reflected XSS im SSL-VPN, CVSS 6.1 (14.07.2026)
• [[13]] NVD: CVE-2026-23573