FortiBleed: Warum der Patch allein nicht reicht (CVE-2026-25089)

In den vergangenen Tagen sind zwei Fortinet-Themen zusammengefallen, die jeder Betreiber einer FortiGate oder FortiSandbox auseinanderhalten sollte: drei aktiv ausgenutzte FortiSandbox-Lücken auf der einen Seite - und „FortiBleed", eine groß angelegte Kampagne gegen FortiGate-Firewalls, auf der anderen.

Die Schlagzeile zu FortiBleed lautet verkürzt: „Admin-Passwörter geknackt." Das ist richtig und zugleich irreführend. Denn die wichtigste Konsequenz dieser Kampagne ist eine, die in vielen Reaktionen untergeht: Ein eingespielter Patch beendet das Risiko nicht automatisch. Wer das nicht versteht, aktualisiert seine Geräte – und bleibt trotzdem angreifbar.

Dieser Beitrag erklärt, was tatsächlich passiert ist, warum „gepatcht" und „sicher" hier nicht dasselbe sind, und welche Schritte jetzt in welcher Reihenfolge zählen.

Zwei Ereignisse, ein Hersteller

FortiSandbox und FortiBleed sind technisch getrennte Vorgänge. Sie treffen nur denselben Hersteller - und in vielen Umgebungen dieselben Verantwortlichen. Beide verlangen eine Reaktion. Aber aus unterschiedlichen Gründen.

• FortiSandbox: drei schwerwiegende Schwachstellen, die seit dem 16. Juni 2026 aktiv ausgenutzt werden.


• FortiBleed: keine einzelne Schwachstelle, sondern eine mehrstufige Kampagne, die auf erbeutete Konfigurationsdaten, schwache Passwort-Hashes und Anmeldedaten aus Infostealer-Datenbanken aufsetzt.

Die drei FortiSandbox-Lücken

Alle drei Schwachstellen sind als kritisch eingestuft, mit CVSS-Werten zwischen 9,1 und 9,8. Berichte über aktive Ausnutzung liegen seit dem 16. Juni 2026 vor – beobachtet von der Threat-Intelligence-Firma Defused.

Zwei der drei Lücken sind bereits seit dem 14. April 2026 gepatcht. Angreifer haben das Zeitfenster von rund zwei Monaten zwischen Patch-Verfügbarkeit und der beobachteten Ausnutzung Mitte Juni genutzt – ein wiederkehrendes Muster, das weniger über den Hersteller aussagt als über die Realität des Patch-Managements in vielen Organisationen. Für CVE-2026-25089 kursiert Exploit-Code, der nach Einschätzung von Sicherheitsforschern fehlerhaft ist; die Ausnutzung ist hier bislang eingeschränkt, aber bestätigt.

Betroffene Versionen: FortiSandbox 5.0.0 bis 5.0.5 sowie 4.4.0 bis 4.4.8. Behoben in 5.0.6 und höher bzw. 4.4.9 und höher. Für die Versionsreihe 4.2.x ist der Fortinet-Support zu kontaktieren.

FortiBleed: kein einzelnes CVE, sondern eine Kette

„Admin-Passwörter geknackt" suggeriert eine einzelne Lücke. Tatsächlich ist FortiBleed das Ergebnis von drei kombinierten Schritten:

• Schritt 1 - Konfigurationsdaten erbeuten: Der am besten belegte Weg führt über CVE-2026-24858, einen Authentifizierungs-Bypass im FortiCloud-SSO (SAML, CVSS bis 9,8, seit Januar 2026 bekannt und im KEV-Katalog der US-Behörde CISA gelistet). Auf Geräten mit aktivem FortiCloud-SSO ließ sich damit ohne gültige Zugangsdaten ein Administrator-Zugang erzeugen und die Konfiguration auslesen. Das BSI hatte bereits Anfang 2026 vor dieser SAML-SSO-Schwachstelle gewarnt – mit dem bemerkenswerten Hinweis, dass Angriffe selbst dann erfolgreich waren, wenn die Geräte aktuelle Patchstände aufwiesen. Ob alle erbeuteten Konfigurationsdaten aus diesem Weg stammen, ist nicht abschließend geklärt – diskutiert werden auch ältere Schwachstellen wie CVE-2022-40684 und CVE-2024-21762.


• Schritt 2 - Passwörter offline knacken: Hier liegt der eigentliche Hebel. FortiOS speicherte administrative Passwörter bis zu den Versionen 7.2.11, 7.4.8 und 7.6.1 als SHA-256-Hash – ein schneller Hash, der sich mit GPU-Clustern effizient offline berechnen lässt. Berichten zufolge kam ein Verbund von 45 GPUs zum Einsatz. Das Ergebnis sind keine Hashes, sondern verwertbare Klartextpasswörter.


• Schritt 3 - Anmeldedaten durchprobieren: Parallel liefen rund 1,16 Milliarden Anmeldeversuche gegen über 320.000 FortiGate-Ziele – gespeist aus historischen Infostealer-Datenbanken, also aus Zugangsdaten, die zuvor von infizierten Endgeräten abgegriffen wurden.

Das Resultat der Kampagne nach Angaben von Hudson Rock: 73.932 betroffene Firewall-URLs in 194 Ländern, verteilt auf 21.632 Domains. Ein zweiter Sicherheitsdienstleister, SOCRadar, hat unabhängig mehr als 30.000 funktionierende Administrator-Zugangsdaten verifiziert.

Eine Einordnung der Täterschaft kursiert ebenfalls. Sie ist einseitig belegt, und Spekulationen darüber gehören nicht in eine sachliche Lagebewertung – deshalb lassen wir sie hier bewusst aus.

Warum „gepatcht" nicht „sicher" bedeutet

Das ist der Punkt, an dem viele Reaktionen zu kurz greifen.

Fortinet hat die Passwortspeicherung vom schnellen SHA-256 auf das deutlich widerstandsfähigere PBKDF2 umgestellt. Der entscheidende Haken: Die Umstellung greift erst, wenn sich ein Administrator nach dem Update aktiv neu anmeldet. Wer die Firmware aktualisiert, sich aber nicht einloggt, speichert sein Passwort weiterhin als SHA-256 – und bleibt damit angreifbar.

Und selbst nach der Migration gilt: Wenn ein Passwort bereits erbeutet und geknackt wurde, schützt der bessere Hash-Algorithmus nicht. Das alte Passwort ist im Umlauf. Nur ein Reset macht es wertlos.

Daraus folgt eine Reihenfolge, die nicht beliebig ist: erst aktualisieren, dann aktiv neu anmelden, dann Passwörter zurücksetzen – nicht umgekehrt. Wer das Passwort vor dem Update ändert, speichert es noch als SHA-256.

Diesen Mechanismus bestätigen mehrere Sicherheitsdienstleister unabhängig - unter anderem Arctic Wolf, mit dem enthus im Bereich Managed Detection & Response zusammenarbeitet.

Sind Sie betroffen?

Hudson Rock stellt unter hudsonrock.com/fortinet eine kostenlose Prüfung bereit, mit der sich die eigene Domain gegen die Kampagnendaten abgleichen lässt. Das ist ein sinnvoller erster Indikator - aber kein Freispruch. Ein negativer Treffer bedeutet nicht, dass die eigene FortiGate sicher konfiguriert ist.

Mindestens ebenso wichtig: ein Blick in die eigenen Logs. Auffällig sind gehäufte Fehlversuche, Anmeldungen außerhalb der Geschäftszeiten und Zugriffe aus Regionen ohne nachvollziehbaren Geschäftsbezug.

Was jetzt zu tun ist - in dieser Reihenfolge

Sofortmaßnahmen

1. Management-Zugang aus dem Internet nehmen: Die Administrationsoberfläche gehört nicht ins offene Netz. Lässt sie sich nicht vollständig deaktivieren, ist der Zugriff über Trusted-Host-Einträge auf wenige, definierte Quell-IP-Adressen zu begrenzen. Wo FortiCloud-SSO nicht benötigt wird: deaktivieren – das verkleinert die Angriffsfläche von CVE-2026-24858.


2. Betroffenheit prüfen: Parallel zur Vorbereitung des Firmware-Updates, nicht nacheinander. Domain-Abgleich über hudsonrock.com/fortinet und Auswertung der Logs auf die oben genannten Auffälligkeiten.


3. Firmware aktualisieren: FortiSandbox auf 5.0.6 / 4.4.9 oder höher; FortiOS auf eine Version mit PBKDF2-Speicherung (7.2.11, 7.4.8, 7.6.1 oder neuer). Dies ist der wichtigste Einzelschritt.


4. Neu anmelden und Passwörter zurücksetzen: Nach dem Update meldet sich jeder Administrator aktiv an, damit die Hash-Migration greift - anschließend werden alle administrativen Passwörter neu gesetzt. Erst jetzt sind die neuen Passwörter sicher gespeichert und alte, möglicherweise erbeutete Zugangsdaten wertlos.


5. Aktive Sitzungen und Token invalidieren: Bestehende Admin-Sessions sowie SAML- und FortiCloud-SSO-Token nach der Passwortänderung gezielt ungültig machen.


6. Wirkungsbereich ausweiten: Erbeutete Firewall-Zugangsdaten ermöglichen laterale Bewegung in angeschlossene Systeme – insbesondere Active Directory. Im Verdachtsfall den Untersuchungsumfang entsprechend ausdehnen und erreichbare Zugangsdaten mitrotieren.

Mittelfristige Maßnahmen

1. Mehr-Faktor-Authentifizierung für alle administrativen Zugänge: Etwa über FortiToken/FortiAnalyzer oder Microsoft Authenticator.


2. Personalisierte Administrator-Konten statt generischer Sammel-Accounts: Nur so sind Aktionen nachvollziehbar und Zugänge gezielt entziehbar.


3. Login-Events zentral überwachen und alarmieren: Über FortiAnalyzer, ein SIEM oder einen Managed-Detection-and-Response-Dienst.


4. Zugriffskonzept grundsätzlich überdenken: Die Management-Ebene einer Firewall gehört hinter ein definiertes Zugriffskonzept, nicht ins offene Internet. ZTNA- und Trusted-Host-Ansätze sind hier die strukturelle Antwort.

Die regulatorische Dimension: NIS-2

Wer den technischen Vorfall behandelt, sollte die regulatorische Seite nicht übersehen. Das deutsche NIS-2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft - ohne Übergangsfrist.

Eine kompromittierte Firewall in einer „wichtigen" oder „besonders wichtigen" Einrichtung ist meldepflichtig. Die Fristen sind eng und beginnen mit der Kenntnis des Vorfalls, nicht mit dem Abschluss der Analyse:

• 24 Stunden: Frühwarnung an das BSI
• 72 Stunden: Folgemeldung mit erster Bewertung
• 1 Monat: Abschlussbericht

Gemeldet wird über das BSI-Meldeportal (MIP). Verstöße können mit Bußgeldern von bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes belegt werden.

Und ein Punkt, der gerade den Mittelstand betrifft: Auch wer selbst nicht unmittelbar NIS-2-pflichtig ist, kann über die Lieferketten-Anforderungen des Gesetzes in der Verantwortung stehen, wenn er Leistungen für regulierte Einrichtungen erbringt.

Die Lektion: Das Management-Interface ist das Kronjuwel

FortiBleed ist kein Fortinet-spezifisches Problem. Es ist ein Lehrstück über zwei Prinzipien, die für jede Firewall, jedes VPN-Gateway und jede zentrale Sicherheitskomponente gelten:

1. Die Management-Ebene ist das wertvollste Ziel im Netz. Sie ins offene Internet zu stellen, ist eine Einladung - unabhängig vom Hersteller.


2. Patch-Stand ist eine Momentaufnahme, kein Dauerzustand. Wer Schwachstellen, Konfiguration und Zugangsdaten nicht zusammen denkt, schließt die eine Tür und lässt die andere offen.

Die unbequeme Frage hinter diesem Vorfall lautet deshalb nicht „Sind wir gepatcht?", sondern: Wissen wir, welche unserer Zugangsdaten im Umlauf sein könnten - und würden wir es merken, wenn sich jemand damit anmeldet?

Sie betreiben FortiGate- oder FortiSandbox-Systeme und wollen wissen, wie Ihre Exposition tatsächlich aussieht?

enthus ist herstellerunabhängig und ohne Verkaufsinteresse an einem bestimmten Firewall-Anbieter. Wir unterstützen bei der Erstbewertung Ihrer Exposition (Cybersecurity Consulting), beim laufenden Monitoring verdächtiger Anmeldeaktivitäten (Managed Detection & Response mit Arctic Wolf) und bei der Einstufung möglicher Meldepflichten (externe ISB-Funktion).

Wenn Sie Unterstützung benötigen, wenden Sie sich bitte an service@enthus.de oder nutzen Sie komfortabel unser Ticketsystem unter enthus.de/portal/servicetickets