VPN SonicWall omija weryfikację dwuetapową: luka już wykorzystywana. Zaktualizuj zaporę

Abstrakcyjna tarcza zapory w serwerowni z niebieskim tunelem VPN przechodzącym przez środek (grafika wygenerowana przez AI)

6 listopada 2026 r. SonicWall opublikował poprawkę do luki CVE-2026-19868 w usłudze SSL VPN systemu SonicOS. Ktoś, kto zna poprawne dane logowania inną metodą niż SAML, może ominąć kontrolę SAML – a wraz z nią weryfikację dwuskładnikową wymuszaną przez dostawcę tożsamości. Tego samego dnia amerykańska agencja CISA wpisała lukę do katalogu podatności już wykorzystywanych w atakach. Producent nie podał obejścia: jedyna skuteczna ochrona to aktualizacja oprogramowania zapory.

Co się stało

Luka dotyczy zapór SonicWall z serii Gen7 i Gen8 oraz usługi zdalnego dostępu SSL VPN. Problem pojawia się, gdy logowanie do VPN-u idzie przez SAML – czyli przez firmowego dostawcę tożsamości, na przykład Microsoft Entra ID (dawniej Azure AD), Google Workspace albo Okta, zwykle z weryfikacją dwuskładnikową.

To błąd egzekwowania reguł logowania, a nie złamanie szyfrowania SAML. Osoba, która ma ważne dane dostępowe inną metodą (lokalne hasło na zaporze albo konto z katalogu LDAP lub RADIUS), może w określonych warunkach dostać sesję VPN z pominięciem ścieżki SAML. Jeśli polityka firmy zakłada, że każdy dostęp zdalny musi przejść przez MFA u dostawcy tożsamości, ta ochrona może wtedy nie zadziałać. SonicWall ocenił lukę na 7,1 w skali CVSS, czyli jako wysoką.

Zespół bezpieczeństwa producenta zbadał zgłoszenie wskazujące, że luka mogła zostać wykorzystana. Szczegółów ataków, liczby ofiar ani wskaźników kompromitacji nie opublikowano. CISA dodała CVE-2026-19868 do katalogu Known Exploited Vulnerabilities jeszcze 6 listopada i dała amerykańskim agencjom federalnym czas do 20 listopada 2026 r. Kanadyjski ośrodek cyberbezpieczeństwa w komunikacie z tego samego dnia również potwierdza, że SonicWall wskazuje na wykorzystywanie tej podatności.

Kogo to dotyczy

Narażone są zapory Gen7 (modele TZ, NSa, NSsp oraz wirtualne NSv) z oprogramowaniem SonicOS w wersji 7.3.3-7015 i starszej oraz zapory Gen8 (TZ, NSa i NSv) z wersją 8.2.2-8015 i starszą. Poprawione wydania to 7.3.4-7013 (Gen7) i 8.2.3-8015 (Gen8). Usługa SSL VPN jest narażona tylko wtedy, gdy włączone jest logowanie SAML.

W Polsce takie urządzenia często chronią pracę zdalną w małych i średnich firmach, biurach rachunkowych, szkołach, przychodniach i samorządach: pracownik łączy się z domu, a logowanie idzie przez firmowe konto Microsoft albo Google. Właśnie taki układ – SAML plus dodatkowa, „zapasowa” metoda logowania – jest w centrum tej luki. Sam fakt, że na ekranie widać MFA, nie oznacza, że każda alternatywna ścieżka też je wymusza.

Co zrobić od razu

SonicWall wprost pisze, że nie ma obejścia, i zaleca jak najszybsze wgranie najnowszego wydania. W praktyce:

  • Sprawdź wersję na każdej zaporze Gen7 i Gen8, także na instancjach wirtualnych NSv (zwykle w System → Status).
  • Ustal, czy SSL VPN korzysta z SAML – te urządzenia aktualizuj w pierwszej kolejności. Pozostałe i tak warto zaktualizować, bo w tym samym komunikacie jest jeszcze sześć innych luk, w tym dwie w interfejsie zarządzania ocenione na 8,8 CVSS.
  • Zrób kopię konfiguracji, a potem wgraj poprawkę: Gen7 do 7.3.4-7013 lub nowszej, Gen8 do 8.2.3-8015 lub nowszej. Potem sprawdź, czy logowanie SAML, MFA i zasady dostępu nadal działają.
  • Przejrzyj dzienniki logowań VPN pod kątem udanych sesji użytkowników SAML inną metodą niż zwykle, nietypowych lokalizacji oraz zmian w konfiguracji zapory.
  • Jeśli coś wygląda podejrzanie, traktuj konto jak przejęte: zmień hasło z zaufanego miejsca, zakończ aktywne sesje i sprawdź, do jakich zasobów ta osoba miała dostęp przez VPN.

Dopóki nie wgrasz poprawki, możesz zmniejszyć ryzyko: zabierz dostęp SSL VPN kontom, które nadal mogą logować się inną metodą niż SAML, i ogranicz źródłowe adresy IP do zaufanych sieci. To nie naprawia luki – tylko zawęża pole ataku do czasu okna serwisowego.

Co jeszcze warto uporządkować

Łatka zamyka konkretny błąd, ale nie usuwa dodatkowych metod logowania włączonych wcześniej. Jeśli konto miało lokalne hasło „na wszelki wypadek”, po aktualizacji ta konfiguracja zwykle zostaje. Warto przy tej okazji wyłączyć zbędne ścieżki. Hasła do VPN-u są częstym celem phishingu, a ta luka właśnie takich danych wymaga – dlatego aktualizacja firmware’u powinna iść w parze z czujnością wobec wiadomości „z IT” proszących o ponowne zalogowanie do sieci firmowej.

Podejrzany incydent związany z zaporą albo nietypowym logowaniem zgłoś zespołowi CERT Polska na incydent.cert.pl.

Źródło: SonicWall PSIRT – komunikat SNWLID-2026-0014, CISA – wpis CVE-2026-19868 do katalogu KEV (6 listopada 2026), katalog Known Exploited Vulnerabilities, SecurityWeek – opis poprawki i wersji, Kanadyjski ośrodek cyberbezpieczeństwa – komunikat AV26-1133

Artykuł zredagowany przy pomocy AI.

Śledzę AI, dotacje i cyberbezpieczeństwo, żebyś Ty nie musiał. Codziennie wybieram to, co naprawdę ważne, i podaję w pigułce, bez marketingowego bełkotu.

Opublikuj komentarz

Prawdopodobnie można pominąć