CVE-2026-19868 zeigt, warum ein Pentest den kompletten VPN-Anmeldeweg testen muss: Eine sichtbare MFA-Abfrage beweist nicht, dass sie bei jedem erlaubten Login-Pfad durchgesetzt wird. Bei SonicWall SonicOS SSLVPN kann laut CISA ein Nutzer mit gültigen Zugangsdaten für eine alternative Authentifizierungsmethode SAML-Kontrollen umgehen; damit kann auch die über SAML erzwungene MFA umgangen werden.

Stand: 09.11.2026

Auf einen Blick

  • CVE-2026-19868 betrifft SonicOS SSLVPN mit SAML-Authentifizierung.
  • Der Fehler betrifft die Durchsetzung von Authentifizierung, nicht die bloße Existenz eines zweiten Faktors.
  • Betroffene Organisationen sollten den Herstellerhinweis prüfen, aktualisieren und alternative Login-Wege testen.
  • Ein Pentest sollte Identitätsanbieter, VPN-Gateway, Konten und Protokolle als zusammenhängenden Ablauf prüfen.

Was ist bei CVE-2026-19868 passiert?

Die US-Cybersicherheitsbehörde CISA nahm CVE-2026-19868 am 06.11.2026 in ihren Katalog bekannter ausgenutzter Schwachstellen auf. Die dort veröffentlichte Beschreibung betrifft SonicWall SonicOS SSLVPN: Gültige Zugangsdaten für eine alternative Authentifizierungsmethode können ausreichen, um SAML-Authentifizierungskontrollen zu umgehen. Die Folge kann sein, dass eine über SAML vorgeschriebene Mehrfaktor-Authentifizierung nicht mehr greift.

Das ist ein wichtiger Unterschied für den Betrieb. MFA ist keine Eigenschaft, die ein System einmal besitzt und dann überall automatisch durchsetzt. Sie hängt an konkreten Abläufen: Welcher Client meldet sich an? Welche Benutzergruppe darf welchen Mechanismus verwenden? Gibt es lokale, LDAP-, RADIUS- oder Notfallzugänge? Und welche Regel entscheidet am Gateway, ob SAML zwingend ist?

Warum ist das ein Pentest-Thema und nicht nur ein Patch-Thema?

Ein Update nach Herstelleranleitung ist der erste Schritt, aber kein Ersatz für einen Nachweis im eigenen Setup. Ein Pentest prüft nicht nur, ob eine CVE im Scanner auftaucht. Er prüft, ob ein externer Zugriff in der konkreten Konfiguration tatsächlich an MFA, Rollen, Netzsegmenten und Monitoring scheitert.

Gerade VPN-Zugänge sind dafür zentral: Sie verbinden das öffentliche Internet mit administrativen oder internen Ressourcen. Ein Fehler im Identitäts- und Zugriffspfad kann daher stärker wiegen als eine isolierte Schwachstelle auf einem einzelnen Arbeitsplatz. Die Pentesting-Leistung von FEHMER TECH setzt deshalb auf einen klar definierten Scope, nachvollziehbare Findings und einen Retest, statt nur einen automatisierten Scan zu liefern.

Welche Login-Wege sollte ein Pentest abdecken?

Für einen aussagekräftigen Test reicht es nicht, sich einmal mit einem Standardkonto über den vorgesehenen Browser-Flow anzumelden. Die Prüfung sollte autorisiert und kontrolliert alle Wege einbeziehen, die im eigenen Betrieb erlaubt oder technisch erreichbar sind:

  • SAML-Anmeldung über den vorgesehenen Identity Provider und die erwartete MFA-Abfrage.
  • Alternative Authentifizierungsmethoden, etwa lokale Konten oder angebundene Verzeichnisdienste, sofern vorhanden.
  • Unterschiedliche Benutzergruppen, besonders Admin-, Service- und Notfallkonten.
  • VPN-Clients, Web-Portal und mobile Zugriffe, wenn sie unterschiedliche Policies verwenden.
  • Verhalten nach Fehlversuchen, Passwortwechseln und deaktivierter MFA.
  • Protokollierung im Gateway und beim Identity Provider: Ist ein abweichender Login erkennbar und alarmierbar?

Die Details müssen vor dem Test im Scope stehen. Ein Pentest ist kein unangekündigter Ausfalltest: erlaubte Systeme, Testfenster, Testkonten, Abbruchkriterien und Ansprechpartner gehören schriftlich festgelegt. So lassen sich reale Risiken prüfen, ohne den Betrieb unnötig zu gefährden.

Was sollten KMU jetzt konkret tun?

Prüfen Sie zuerst, ob SonicOS SSLVPN mit SAML in Ihrer Umgebung eingesetzt wird. Der maßgebliche technische Stand ist der SonicWall-PSIRT-Hinweis SNWLID-2026-0014; dort gehören betroffene Versionen und die vom Hersteller genannten Korrekturen verifiziert. Planen Sie das Update nach Ihrem Change-Prozess und halten Sie vorab eine Rückfallmöglichkeit bereit.

Danach folgt die Konfigurationsprüfung: Inventarisieren Sie alle aktivierten Authentifizierungsquellen und klären Sie, ob jede davon SAML samt MFA zwingend durchlaufen muss. Nicht benötigte alternative Login-Wege sollten deaktiviert oder zumindest auf klar begrenzte Notfallkonten reduziert werden. Prüfen Sie außerdem, ob erfolgreiche VPN-Anmeldungen zentral protokolliert werden und ob ungewöhnliche Authentifizierungswege auffallen.

Ein IT-Security-Check hilft, diese Maßnahmen mit Rollen, Netzwerkzugängen, Monitoring und Betriebsdokumentation zu verbinden. Für den belastbaren Nachweis folgt ein begrenzter Pentest oder Retest des Login-Pfads nach dem Update. Entscheidend ist das Ergebnis im laufenden System, nicht nur der Haken bei „MFA aktiviert“ in einer Verwaltungsoberfläche.

Welche Nachweise gehören in den Abschluss?

Nach der Behebung sollten Verantwortliche festhalten, welche Softwareversion am Gateway läuft, welche Login-Wege erlaubt sind und welche Testkonten verwendet wurden. Der Testnachweis sollte zeigen, dass alternative Pfade die SAML-Pflicht nicht mehr umgehen können und dass erfolglose wie erfolgreiche Anmeldeversuche in den vorgesehenen Logs erscheinen. Zusätzlich ist ein kurzer Wiederholungstermin sinnvoll, wenn Identity Provider, VPN-Client oder Gruppenrichtlinien geändert werden.

Wie bleibt der Test sicher und aussagekräftig?

Die Prüfung braucht keine produktiven Passwörter in einem Report und keine unkontrollierten Versuche gegen das Live-System. Sinnvoll sind eigens eingerichtete Testkonten mit dokumentierten Rollen sowie ein abgestimmtes Zeitfenster. Das Betriebsteam sollte während des Tests erreichbar sein und die erwarteten Ereignisse in Gateway- und Identity-Provider-Logs nachvollziehen können. Werden unerwartete Seiteneffekte sichtbar, etwa Sperren, erhöhte Fehlerraten oder Zugriffe auf nicht vereinbarte Segmente, greift ein vorher definierter Abbruchweg. Genau diese Vorbereitung trennt einen belastbaren Pentest von einer rein technischen Momentaufnahme.

Nach dem Retest gehört das Ergebnis in die Betriebsdokumentation: Verantwortliche, erlaubte Authentifizierungsquellen, Änderungstermine und die Stelle, an der Anmeldeereignisse überwacht werden. Das macht die Entscheidung bei der nächsten Änderung am VPN nachvollziehbar und verhindert, dass Notfallzugänge dauerhaft unbemerkt zum Standardweg werden.

Fazit

CVE-2026-19868 ist ein aktueller Anlass, die Wirksamkeit von MFA am VPN nicht anzunehmen, sondern zu testen. Aktualisieren Sie nach Herstellerhinweis, reduzieren Sie alternative Authentifizierungspfade und lassen Sie den vollständigen Anmeldefluss kontrolliert prüfen. Für KMU ist das eine überschaubare Maßnahme mit direktem Nutzen für den externen Zugriff.

Quellen