[email protected]

FortiGate-SSL-VPN-Risiko 2026: Warum exponierte VPN-Appliances zur Belastung werden und ZTNA die Alternative ist

FortiGate-SSL-VPN-Risiko 2026: Warum exponierte VPN-Appliances zur Belastung werden und ZTNA die Alternative ist

Hinweis zum Inhalt: Die Informationen in diesem Artikel wurden nach bestem Wissen zum Zeitpunkt der Veröffentlichung zusammengestellt. Technische Details, Preise, Versionen, Lizenzmodelle und externe Inhalte können sich ändern. Bitte prüfen Sie die genannten Angaben eigenständig, insbesondere vor geschäftskritischen oder sicherheitsrelevanten Entscheidungen. Dieser Artikel ersetzt keine individuelle Fach-, Rechts- oder Steuerberatung.

SSL-VPN kontrolliert ablösen: Der Secure-Access-Check erfasst Zugänge und Altlasten und legt Zielmodell und Migrationspfad fest. Der VPN-Migrationssprint setzt das mit Pilotgruppe, Parallelbetrieb und dokumentiertem Rückfallweg um. Den anschließenden Betrieb übernimmt WZ-IT auf Wunsch als Managed NetBird ab 349,90 € netto im Monat mit Monitoring, Updates, Backups und wählbarem Service Level. Secure-Access-Check ansehen · Migrationssprint · Managed NetBird · CVE-Monitoring

Am 27. Januar 2026 nahm die US-Behörde CISA eine aktiv ausgenutzte FortiOS-Lücke in ihren Katalog bekannter ausgenutzter Schwachstellen (KEV) auf und gab US-Bundesbehörden drei Tage Zeit. Fortinet FortiOS CVE-2026-24858 (CVSS 9.8) ist eine Authentication-Bypass-Lücke in der FortiCloud-SSO-Anmeldung: Ein Angreifer mit eigenem FortiCloud-Konto konnte sich an fremden FortiGates anmelden, auch an Geräten mit der damals aktuellen Firmware (Fortinet PSIRT FG-IR-26-060). Fortinet sperrte die beiden missbrauchten FortiCloud-Konten am 22. Januar 2026 und lieferte die Fixes ab dem 27. Januar 2026 aus.

FortiGate ist dabei kein Einzelfall. 2026 ist das Jahr, in dem die internet-exponierte SSL-VPN-Appliance als Kategorie zur Belastung geworden ist. Citrix NetScaler, Ivanti Sentry und FortiClient EMS folgten innerhalb weniger Monate mit eigenen kritischen, aktiv ausgenutzten Lücken. Dieser Beitrag ordnet die Welle ein, erklärt, warum der offene VPN-Port am Netzrand strukturell das Problem ist, und zeigt den praktischen Weg zu identitätsbasiertem ZTNA auf Basis einer souveränen, selbst gehosteten Mesh-Architektur.

Inhaltsverzeichnis

Die VPN-Appliance-Welle 2026 im Faktencheck

Vier Vorfälle in einem halben Jahr zeigen ein Muster, kein Einzelversagen eines Herstellers. Alle Daten gegen NVD und CISA-KEV geprüft (Stand Juni 2026, FortiOS-Zeile im Oktober 2026 korrigiert):

Produkt CVE CVSS Typ Status
FortiOS (FortiCloud SSO) CVE-2026-24858 9.8 Auth-Bypass (Admin-Anmeldung) CISA-KEV 27.01.2026
Citrix NetScaler ADC/Gateway CVE-2026-3055 9.3 Out-of-Bounds-Read / Memory Overread CISA-KEV 30.03.2026
Ivanti Sentry CVE-2026-10520 10.0 pre-auth OS Command Injection (Root) CISA-KEV 11.06.2026
FortiClient EMS CVE-2026-35616 9.8 API-Auth-Bypass ausgenutzt ab ~31.03.2026

FortiOS CVE-2026-24858. Betroffen sind FortiOS 7.0.0-7.0.18, 7.2.0-7.2.12, 7.4.0-7.4.10 und 7.6.0-7.6.5; Fixes in 7.0.19, 7.2.13, 7.4.11 und 7.6.6. Voraussetzung ist die aktivierte FortiCloud-SSO-Administratoranmeldung. Sie ist ab Werk aus, wird aber bei der Registrierung eines Geräts in FortiCare eingeschaltet, sofern der Administrator die Option nicht ausdrücklich deaktiviert.

Citrix NetScaler CVE-2026-3055 (CVSS 9.3) ist ein Out-of-Bounds-Read, der unauthentifiziert Speicherinhalte der Appliance leaken kann, inklusive Session-Tokens. Betroffen sind ausschließlich Appliances, die als SAML Identity Provider konfiguriert sind; die Begleit-CVE-2026-4368 (CVSS 7.7) betrifft Gateway- und AAA-vServer. Citrix veröffentlichte das Advisory am 23. März 2026; CISA nahm die CVE am 30. März 2026 wegen aktiver Ausnutzung in den KEV-Katalog auf. Das Muster erinnert an die NetScaler-Vorfälle der Vorjahre (CitrixBleed).

Ivanti Sentry CVE-2026-10520 erreicht den Maximalwert CVSS 10.0: eine pre-auth OS Command Injection, die nicht authentifizierten Angreifern mit Zugriff auf den Managementport 8443 Root-Code-Ausführung erlaubt. Betroffen sind Sentry 10.5.1, 10.6.1, 10.7.0 und älter (Fixes in 10.5.2, 10.6.2, 10.7.1). Seit dem 11. Juni 2026 im CISA-KEV; Sicherheitsforscher beobachteten Kompromittierungen kurz nach Patch-Release.

FortiClient EMS CVE-2026-35616 (CVSS 9.8) ist ein Improper-Access-Control-/API-Auth-Bypass in den Versionen 7.4.5 und 7.4.6. Besonders perfide: Eine Angreifergruppe nutzte die Lücke, um einen als Fortinet-Patch getarnten Infostealer auf die verwalteten Endpoints auszurollen. CISA nahm die CVE am 6. April 2026 in den KEV-Katalog auf.

Nachtrag vom 12. Oktober 2026: Eine frühere Fassung dieses Beitrags nannte als FortiOS-Lücke CVE-2026-0847 und eine CISA-Direktive vom 26. Februar 2026. Das war falsch: CVE-2026-0847 betrifft laut NVD die Python-Bibliothek NLTK, und die CISA-Notfalldirektive ED 26-03 vom 25. Februar 2026 betraf Cisco SD-WAN. Der Abschnitt nennt jetzt die tatsächlich ausgenutzte FortiOS-Lücke CVE-2026-24858. Seit Juni hat CISA zwei weitere FortiOS-Lücken in den KEV-Katalog aufgenommen: CVE-2025-68686 (Umgehung des Schutzes gegen den Symlink-Persistenzmechanismus auf bereits kompromittierten Geräten, seit 27. Juli 2026) und CVE-2025-25249 (Heap-Overflow im CAPWAP-Dienst cw_acd, seit 9. September 2026). CVE-2025-25249 ist in FortiOS 7.0.18, 7.2.12, 7.4.9 und 7.6.4 behoben, für FortiOS 6.4 gibt es keinen Fix (Fortinet PSIRT FG-IR-25-084). Für US-Bundesbehörden gilt seit dem 10. Juni 2026 BOD 26-04; sie ersetzt BOD 22-01 und BOD 19-02 und priorisiert nach öffentlicher Erreichbarkeit, KEV-Status, Automatisierbarkeit des Exploits und technischer Auswirkung; die kürzeste Frist beträgt drei Tage plus forensische Prüfung.

Warum die SSL-VPN-Appliance zur Belastung wird

Das gemeinsame Muster ist nicht der einzelne Bug, sondern die Architektur. Eine klassische SSL-VPN-Appliance ist ein internet-exponierter, hochprivilegierter Single Point of Failure:

  • Sie hat per Definition einen offenen Port am Internet-Rand (typisch 443), den jeder Scanner findet. Suchmaschinen wie Shodan indexieren exponierte FortiGates, NetScaler und Ivanti-Gateways fortlaufend.
  • Nach erfolgreicher Anmeldung gewährt sie häufig flachen Netzzugriff, der kompromittierte VPN-Endpunkt wird zum Sprungbrett für Lateral Movement.
  • Sie terminiert TLS, hält Credentials und Session-Tokens im Speicher und ist damit ein lohnendes Ziel für Memory-Leaks (siehe NetScaler) und Auth-Bypässe (siehe FortiOS).
  • Patches erfordern Wartungsfenster, HA-Failover und Funktionstests. Das Zeitfenster zwischen Disclosure und Rollout ist genau das Fenster, in dem Massen-Scanning läuft.

Das ist kein Fortinet-spezifisches Problem. Dieselbe strukturelle Schwäche haben wir bereits bei Cisco ASA und ArcaneDoor beschrieben. Solange der Zugriffsweg ein offener, anonym erreichbarer Listener ist, bleibt jede neue Lücke in der Appliance ein potenzieller Vollzugriff aufs Netz.

Fortinet zieht selbst den Stecker: FortiOS 7.6.3

Die Diskussion, ob eine exponierte SSL-VPN-Appliance noch zeitgemäß ist, hat der Hersteller inzwischen selbst beendet. Ab FortiOS 7.6.3 ist der SSL-VPN-Tunnelmodus vollständig entfernt - weder in der GUI noch in der CLI verfügbar, und zwar auf allen FortiGate-Modellen (FortiOS-Release-Notes).

Zwei Details machen das zu einem harten Termin statt zu einer Empfehlung:

  • Bestehende Konfigurationen werden nicht übernommen. Sämtliche Einstellungen zum SSL-VPN-Tunnelmodus inklusive der zugehörigen Firewall-Policies überstehen das Upgrade nicht.
  • Wer ungeprüft aktualisiert, verliert den Fernzugriff. Fortinet weist ausdrücklich darauf hin, dass die Umstellung vor dem Upgrade erfolgen muss, um den Zugang nicht zu unterbrechen.

Als direkten Nachfolger nennt Fortinet IPsec, wahlweise über TCP 443 für restriktive Netze. Das ist der Pfad, der Sie im selben Ökosystem hält.

Die eigentliche Frage ist aber eine andere: Wenn ohnehin jede Remote-Access-Konfiguration angefasst werden muss, ist das der günstigste Moment, die Architekturfrage zu stellen. Ein erzwungener Umbau auf IPsec löst das Grundproblem nicht - der internet-exponierte Listener bleibt, die Appliance bleibt der privilegierte Single Point of Failure. Wer stattdessen auf ein identitätsbasiertes Overlay wechselt, nutzt denselben Aufwand für den Schritt, der die Angriffsfläche tatsächlich entfernt.

Von flachem VPN zu identitätsbasiertem ZTNA

Die Antwort auf ein Architekturproblem ist eine andere Architektur. ZTNA (Zero Trust Network Access) dreht das Modell um: Statt "erst ins Netz, dann sehen, was erreichbar ist" gilt "erst Identität und Kontext prüfen, dann genau eine Anwendung freigeben". Die Kernunterschiede:

  • Kein anonymer Listener am Internet-Rand. Verbindungen werden ausgehend und identitätsbasiert aufgebaut; es gibt keinen offenen Port, der vorab eine Authentifizierung anbietet.
  • Zugriff pro Anwendung statt aufs ganze Netz. Eine Richtlinie wie "Gruppe Wartung darf SPS-Subnetz an Standort B erreichen" ersetzt den flachen Tunnel.
  • Identität, Gerätezustand und Kontext entscheiden über jeden Zugriff, nicht ein einmal validiertes VPN-Login.
  • Vollständiger Audit-Trail: Wer hat wann auf welche Anwendung zugegriffen. Das ist die Grundlage für NIS2-Nachweise.

Was ZTNA genau bedeutet und wie es sich vom klassischen VPN abgrenzt, vertieft unser Wissensartikel Was ist ZTNA?. Wichtig: ZTNA ist kein Produkt eines einzelnen Herstellers, sondern ein Architekturprinzip, umsetzbar mit kommerziellen Clouds (Zscaler, Cloudflare, Twingate) oder mit souveränen, selbst gehosteten Open-Source-Komponenten. Wie die Ablösung unabhängig vom Hersteller abläuft, von der Bestandsaufnahme über das Zielmodell bis zur Abschaltung des Gateways, beschreibt der Leitfaden VPN ablösen.

NetBird plus IdP als souveräne Mesh-Alternative

Für DACH-Unternehmen mit Souveränitätsanspruch ist die selbst gehostete Variante besonders attraktiv. NetBird ist eine in Berlin entwickelte, WireGuard-basierte Zero-Trust-Mesh-Plattform unter BSD-3-Lizenz. Management-Server, Signal-Server und Relay (TURN) sind Open Source und vollständig selbst hostbar.

Statt eines exponierten Konzentrators entsteht ein flaches, peer-to-peer verschlüsseltes Overlay: Jeder Knoten erreicht jeden anderen direkt, sofern die Richtlinie es erlaubt. Es gibt keinen zentralen Internet-Listener als Single Point of Failure. Auf das WireGuard-Fundament setzt NetBird eine Management-Ebene mit:

  • SSO-/IdP-Anbindung an Keycloak, Authentik oder Entra ID, die Identität kommt aus dem eigenen Verzeichnis, nicht aus der VPN-Box.
  • Gruppenbasierten Zugriffsrichtlinien (Netzwerk-Segmentierung pro Anwendung).
  • Audit-Trail über alle Verbindungen.

Der Souveränitätsvorteil: Steuerebene und Datenebene laufen auf eigener oder EU-Infrastruktur, der IdP bleibt im Haus, es gibt keine Abhängigkeit von einer US-Cloud. NetBird hat im Januar 2026 eine Series A über 8,5 Mio. Euro abgeschlossen und wird aktiv weiterentwickelt. Eine Einordnung gegenüber Tailscale und reinem WireGuard liefert unser Vergleich NetBird vs. Tailscale vs. WireGuard. Wer ein reines WireGuard-Fundament für die Standortanbindung braucht, findet die Optionen auf unserer WireGuard-Expertiseseite.

In der Praxis betreiben wir genau dieses Modell produktiv: Bei ABCO Water Systems in Australien erfolgt die sichere Fernwartung von Maschinen und Anlagen über ein identitätsbasiertes Mesh statt über einen exponierten VPN-Konzentrator.

Migrationspfad in fünf Schritten

Ein Wechsel muss kein Big-Bang-Cutover sein. Bewährt hat sich der parallele Aufbau:

  1. Bestandsaufnahme und Audit. Welche VPN-Appliances sind internet-exponiert? Welche Versionen, welche offenen CVEs, welche Nutzer- und Maschinenzugänge laufen darüber? Das ist der Kern unseres Security-Audits.
  2. IdP als Single Source of Truth. Identitäten, Gruppen und MFA in Keycloak, Authentik oder Entra ID konsolidieren. Ohne sauberen IdP gibt es kein belastbares ZTNA.
  3. Mesh-Pilot. NetBird-Steuerebene auf eigener oder EU-Infrastruktur aufsetzen, erste Nutzergruppe und ein nicht kritisches Zielsystem per Richtlinie anbinden, Audit-Logging verifizieren.
  4. Schrittweise Migration. Nutzergruppen und Maschinenzugänge nacheinander vom SSL-VPN auf das Mesh umstellen. Die FortiGate bleibt vorerst als Firewall und für Site-to-Site-Tunnel im Einsatz.
  5. Listener abschalten. Sobald keine Endnutzer mehr über den SSL-VPN-Dienst gehen, wird der internet-exponierte Listener deaktiviert, die zentrale Angriffsfläche verschwindet.

Den Architekturhintergrund für einen NIS2-konformen Fernzugriff vertieft unser Wissensartikel NIS2-konformer Fernzugriff.

NIS2 und die Haftungsfrage

Die deutsche NIS2-Umsetzung verpflichtet wesentliche und wichtige Einrichtungen zu dokumentiertem Risikomanagement, explizit inklusive Schwachstellen- und Patch-Management (Paragraf 30 BSIG), sowie zu Meldepflichten binnen 24 und 72 Stunden (Paragraf 32 BSIG). Hinzu kommt die Verantwortung der Geschäftsleitung (Paragraf 38 BSIG); Bußgelder reichen für besonders wichtige Einrichtungen bis 10 Mio. Euro oder 2 Prozent des weltweiten Jahresumsatzes (Paragraf 65 BSIG).

Eine internet-exponierte VPN-Appliance mit einer bekannten CVSS-9.8-Lücke, die mangels Patch-SLA wochenlang ungepatcht läuft, ist bei einer Prüfung durch das BSI oder nach einem meldepflichtigen Vorfall ein klassischer Befund. Wer dagegen einen dokumentierten CVE-Monitoring- und Patch-Prozess sowie eine identitätsbasierte, segmentierte Zugriffsarchitektur mit Audit-Trail nachweisen kann, erfüllt mehrere Anforderungen gleichzeitig.

Dieser Beitrag ist allgemeine Information und keine Rechtsberatung. Wir sind Ingenieure, keine Juristen, die konkrete Bewertung Ihrer NIS2-Pflichten gehört in fachkundige rechtliche Hände.

Noch unklar, welches Werkzeug passt? Der Orientierungsworkshop ordnet Ihre Anforderungen und liefert eine priorisierte Themenliste mit Empfehlung je Thema. Ab 1.490 € netto, remote.

Unser Vorgehen bei WZ-IT

WZ-IT ist ein deutscher Managed-Service-Provider für souveräne IT und managed Open Source. Bei der Ablösung internet-exponierter VPN-Appliances arbeiten wir so:

  • Security-Audit zuerst. Wir kartieren die Angriffsfläche: exponierte Appliances, Versionsstände, offene CVEs, Zugriffswege. Ergebnis ist ein priorisierter Maßnahmenplan, siehe Security-Audit.
  • Souveräne Mesh-Plattform statt Konzentrator. Wir bauen und betreiben NetBird-basierte Remote-Management-Plattformen auf eigener oder Ihrer EU-Infrastruktur, mit Anbindung an Ihren IdP und gruppenbasierten Richtlinien.
  • CVE-Monitoring und Patch-SLA. Tägliche Prüfung gegen NVD, CISA-KEV, CERT-Bund und BSI, mit dokumentierter Reaktion als Anlage zur NIS2-Risikomanagement-Doku. Mehr unter CVE-Monitoring.
  • Parallelbetrieb und sauberer Cutover. Die bestehende Firewall bleibt im Betrieb, der SSL-VPN-Listener wird erst abgeschaltet, wenn alle Zugänge migriert und verifiziert sind.
  • NIS2-konforme Dokumentation. Architektur, Richtlinien und Audit-Trail werden so dokumentiert, dass sie einem Audit standhalten.

Weiterführende Guides

Sie betreiben eine FortiGate-, Citrix- oder Ivanti-Appliance mit internet-exponiertem SSL-VPN und wollen die Angriffsfläche reduzieren? Wir prüfen Ihren Fernzugriff im Security-Audit und planen den Umstieg auf eine souveräne, identitätsbasierte Mesh-Architektur, ohne Big-Bang-Cutover.

Erstgespräch buchen · Remote-Management-Plattformen · CVE-Monitoring

Quellen

Timo Wevelsiep

Geschrieben von

Timo Wevelsiep

Co-Founder & CEO

Co-Founder von WZ-IT. Spezialisiert auf Cloud-Infrastruktur, Open-Source-Plattformen und Managed Services für KMUs und Enterprise-Kunden weltweit.

Häufig gestellte Fragen

Antworten auf wichtige Fragen zu diesem Thema

Kunden aus Mittelstand, Industrie und öffentlicher Hand, in Deutschland und international

  • Stadtwerke Brühl
  • DGHO e.V.
  • solarwerkstatt berlin
  • Krüger Dirndl
  • ABCO Water Systems
  • Golem.de
  • EVADXB
  • nextGYM
  • AInergy
  • ml&s
  • Odiseo Solutions
  • Annota
  • ARGE
  • SweetConnect GmbH
  • Aphy AG
  • CORGOS
  • Rekorder
  • SolidProof
  • Yonju
  • Keymate
  • Paritel
  • Mr. Clipart
  • Millenium
  • Negosh
  • Führerscheinmacher
  • BTI
  • Deutsche Gesellschaft für Datenschutz
Kundenstimmen ansehen

Anfrage

Vom exponierten SSL-VPN kontrolliert zu ZTNA wechseln

Wir erfassen FortiGate-, Citrix- oder Ivanti-Risiken, schließen aktuelle Patch-Lücken, prüfen bei Auffälligkeiten einen möglichen Vorfall und planen die parallele Migration auf ein souveränes Mesh.

  • Direkt mit Timo und Robin - kein Vertrieb, kein Sales-Pitch
  • Fachliche Einschätzung Ihrer Situation
  • Konkrete nächste Schritte für Infrastruktur, Software oder KI

Das Gespräch ist unverbindlich und kostenlos.

Die Beratung von WZ-IT zu unserer Azure-Migration war schon im Erstgespräch fachlich sehr fundiert und völlig unverbindlich - wir haben eine Menge mitgenommen.
Jakob ÖschlbergerInno7 GmbH
Timo und Robin, Gründer von WZ-IT

Was ist bei Ihrem Fernzugriff aktuell am dringendsten?

Die Beratung von WZ-IT zu unserer Azure-Migration war schon im Erstgespräch fachlich sehr fundiert und völlig unverbindlich - wir haben eine Menge mitgenommen.
Jakob ÖschlbergerInno7 GmbH