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
- Warum die SSL-VPN-Appliance zur Belastung wird
- Fortinet zieht selbst den Stecker: FortiOS 7.6.3
- Von flachem VPN zu identitätsbasiertem ZTNA
- NetBird plus IdP als souveräne Mesh-Alternative
- Migrationspfad in fünf Schritten
- NIS2 und die Haftungsfrage
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
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:
- 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.
- 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.
- Mesh-Pilot. NetBird-Steuerebene auf eigener oder EU-Infrastruktur aufsetzen, erste Nutzergruppe und ein nicht kritisches Zielsystem per Richtlinie anbinden, Audit-Logging verifizieren.
- 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.
- 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
- Was ist ZTNA? Zero Trust Network Access erklärt - das Architekturprinzip hinter dem Umstieg
- Was ist NetBird? - die souveräne, selbst gehostete Mesh-Plattform
- NetBird vs. Tailscale vs. WireGuard - die Optionen im Vergleich
- NIS2-konformer Fernzugriff - Architektur und Nachweispflichten
- Sichere Fernwartung von Maschinen und Anlagen - der OT- und Industrie-Anwendungsfall
- Cisco ASA, ArcaneDoor und moderner VPN-Stack - das gleiche Muster bei Edge-Appliances
- CVE-Monitoring als Managed Service - automatisierte Reaktion auf NVD, CISA-KEV, CERT-Bund und BSI
- ABCO Water Systems Case Study - identitätsbasierte Fernwartung in der Praxis
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
- CISA Known Exploited Vulnerabilities Catalog
- CISA BOD 26-04: Prioritizing Security Updates Based on Risk (löst BOD 22-01 ab)
- Fortinet PSIRT FG-IR-26-060 (CVE-2026-24858, FortiCloud SSO Authentication Bypass)
- NVD - CVE-2026-24858
- Fortinet PSIRT FG-IR-25-084 (CVE-2025-25249)
- Fortinet PSIRT FG-IR-26-099 (CVE-2026-35616, FortiClient EMS)
- CISA ED 26-03: Mitigate Vulnerabilities in Cisco SD-WAN Systems
- Citrix Security Bulletin CTX696300 (CVE-2026-3055, CVE-2026-4368)
- Rapid7 - CVE-2026-3055 Citrix NetScaler ADC and Gateway Out-of-Bounds Read
- NVD - CVE-2026-10520 (Ivanti Sentry OS Command Injection)
- Help Net Security - Critical Ivanti Sentry flaw allows root-level RCE (CVE-2026-10520)
- The Hacker News - Fortinet Patches Actively Exploited CVE-2026-35616 in FortiClient EMS
- Arctic Wolf - FortiClient EMS Exploited via CVE-2026-35616 to Deliver EKZ Infostealer
- NetBird - Open Source Zero Trust Networking
- NetBird Dokumentation
- EU-Startups - NetBird raises EUR 8.5 million Series A (Januar 2026)
- Paragraf 30 BSIG - Risikomanagementmaßnahmen
- BSI - NIS-2 und das Cyber-Resilienz-Gesetz













