Zum Hauptinhalt springen

Nachricht

SonicWall-Lücke: Wenn ein zweiter Anmeldeweg MFA aushebelt

CVE-2026-19868 betrifft SonicOS-SSLVPN mit SAML. Welche Voraussetzungen gelten, welche Firmware das Problem behebt und wie ihr die MFA-Durchsetzung prüft.

SonicWall-Lücke: Wenn ein zweiter Anmeldeweg MFA aushebelt
Julian Köhn
|Lesezeit: 3 Minuten

Eine VPN-Anmeldung verlangt MFA. Ein anderer Anmeldeweg erreicht denselben Zugang mit weniger Prüfungen. CVE-2026-19868 zeigt, warum IT-Teams alle zugelassenen Wege prüfen müssen.

CISA führt die SonicWall-Lücke seit dem 6. November im Katalog bekanntermaßen ausgenutzter Schwachstellen. Für betroffene Betreiber steht damit die Prüfung ihrer Systeme an. Welche Konfiguration vorhanden ist und ob das Update eingespielt wurde, sollte sich pro Gerät beantworten lassen.

Welche Konfiguration betroffen ist

Laut SonicWall-Advisory betrifft die Lücke SonicOS-SSLVPN mit aktiviertem SAML für VPN-Anmeldungen. SAML bindet dabei einen zentralen Identitätsdienst in die Anmeldung ein.

Angreifer benötigen gültige Zugangsdaten für ein alternatives Anmeldeverfahren. Unter diesen Voraussetzungen können sie SAML-Kontrollen und gegebenenfalls die darüber erzwungene MFA umgehen. CISA beschreibt diese Bedingungen im KEV-Eintrag. Eine Anmeldung ohne Zugangsdaten ist damit nicht gemeint.

Für eure Prüfung zählt deshalb, welche Anmeldeverfahren die konkrete Firewall tatsächlich zulässt. Eine MFA-Vorgabe für den zentralen Identitätsdienst beantwortet diese Frage noch nicht.

Welche Firmware das Problem behebt

Die vollständige Herstellertabelle nennt Hardware-Firewalls und virtuelle NSv-Systeme beider Generationen:

ProduktzweigBetroffene VersionenBehoben ab
SonicOS Gen7Bis einschließlich 7.3.3-70157.3.4-7013
SonicOS Gen8Bis einschließlich 8.2.2-80158.2.3-8015

Für Gen8 ist 8.2.2-8015 also noch betroffen. Prüft die vollständige Versionsnummer am Gerät und den passenden Produktzweig. SonicWall nennt im geprüften Advisory keinen Workaround.

Unsere Einordnung für den Betrieb: Erfasst auch virtuelle Appliances und getrennte Kundenumgebungen. Bei mehreren betreuten Systemen kann die Firmware je Gerät abweichen. Ein zentraler Vermerk wie "SonicWall aktualisiert" reicht als Prüfnachweis dafür nicht aus.

Prüft die MFA-Durchsetzung auf den erlaubten Anmeldewegen

Für die Abnahme nach dem Herstellerupdate empfehlen wir einen kontrollierten Funktionstest. Nutzt dafür freigegebene Testkonten und stimmt ihn mit den Betriebsverantwortlichen ab.

  1. Erfasst Modell, Generation, Firmware und die verwendete SSLVPN-Konfiguration. Ordnet dem System den zuständigen Betreiber zu.
  2. Listet die tatsächlich zugelassenen Anmeldeverfahren und Identitätsquellen auf. Haltet fest, für welche Konten und Zugangsrollen sie gelten.
  3. Beschreibt das erwartete Verhalten je Anmeldeweg. Dazu gehört, welche Faktoren vor einer erfolgreichen VPN-Anmeldung verlangt werden und was bei einer abgelehnten Prüfung passieren soll.
  4. Prüft dieses Verhalten nach dem Update. Dokumentiert den getesteten Weg und das Ergebnis. Verwendet keine echten Passwörter oder Token in Screenshots und Tickets.
  5. Kontrolliert vereinbarte Ausnahmen. Ein Notfallzugang braucht einen benannten Zweck, passende Berechtigungen und eine überprüfte Nutzungsvorgabe.

Diese Schritte sind unsere Empfehlung für die betriebliche Abnahme. Die Herstellerhinweise bleiben maßgeblich für das konkrete Update. Das Abschalten von SAML oder MFA empfehlen wir hier nicht als Ersatzmaßnahme.

Bei auffälligen Anmeldungen den Vorfall gesondert prüfen

Falls eure Überwachung verdächtige Zugriffe zeigt, prüft zusätzlich die betroffenen Konten und Sitzungen. Zieht die zuständigen Sicherheitsteams hinzu und sichert relevante Spuren nach eurem Incident-Prozess. Ein abgeschlossener Updateauftrag ist kein Nachweis darüber, wer zuvor Zugriff hatte.

Welche weiteren Schritte nötig sind, hängt von den tatsächlichen Befunden ab. Der Incident Report hilft, Zeitverlauf, betroffene Systeme, Auswirkungen und Entscheidungen gemeinsam festzuhalten.

Verantwortung und Prüfergebnis pro System festhalten

Für IT-Leitung und MSPs bleibt eine konkrete Aufgabe: Welches System ist betroffen, wer aktualisiert es und wer nimmt den Zugang anschließend ab? Verknüpft die Firmwareprüfung mit dem Updateauftrag und dem Funktionstest. Offene Systeme bleiben einzeln sichtbar.

In Kopexa könnt ihr betroffene Assets mit Risiken, Maßnahmen und Prüfnachweisen verbinden. Die Firmware aktualisiert ihr mit euren Betriebswerkzeugen. Den Arbeitsstand und die Zuständigkeit führt ihr im Zusammenhang mit dem betroffenen System.

Quellenstand: 7. November 2026. Die Grafik ist eine eigene schematische Darstellung der Anmeldewege, keine SonicWall-Produktoberfläche.

Quellen

  1. SonicWall: SonicOS SAML authentication bypass, SNWLID-2026-0014 () [Abgerufen am ]
  2. SonicWall: Originaldaten zu SNWLID-2026-0014 [Abgerufen am ]
  3. CISA: Known Exploited Vulnerabilities Catalog, CVE-2026-19868 [Abgerufen am ]