SonicWall SMA 1000 pod aktywnym atakiem: CVE-2026-15409 i CVE-2026-15410

SonicWall potwierdził aktywne wykorzystanie dwóch podatności w urządzeniach Secure Mobile Access 1000. CVE-2026-15409 to SSRF oceniony na CVSS 10.0, a CVE-2026-15410 umożliwia zdalne wykonanie kodu i ma ocenę 7.2. W tej sytuacji aktualizacja jest konieczna, ale może być niewystarczająca: urządzenie mogło zostać przejęte przed instalacją poprawki.

Producent opublikował nie tylko wersje naprawione, lecz także konkretne ślady w logach i zalecenie pełnej analizy forensic. To ważna różnica. Komunikat „patched” zamyka podatność, ale nie usuwa webshella, zmienionej konfiguracji ani skradzionych poświadczeń.

Które wersje są objęte komunikatem

Advisory dotyczy SMA 1000 modeli 6210, 7210, 8200v oraz CMS na wszystkich obsługiwanych hypervisorach.

Linia	Wersje wskazane jako podatne	Wersja naprawiona
12.4.3	03245, 03387, 03434	12.4.3-03453 lub nowsza
12.5.0	02283, 02624, 02800	12.5.0-02835 lub nowsza

Wersję należy odczytać bezpośrednio z AMC/CMC każdego urządzenia. Nie opieraj decyzji na nazwie pliku w repozytorium, planie zmiany ani deklaracji, że „ostatni hotfix był wdrażany”. W klastrze jeden pominięty węzeł zachowuje podatną powierzchnię.

Dlaczego SSRF i RCE na bramie dostępowej są tak niebezpieczne

SMA znajduje się na granicy między Internetem a dostępem zdalnym do organizacji. SSRF może pozwolić napastnikowi nakłonić urządzenie do wykonywania żądań w jego własnym kontekście i docierania do zasobów niewidocznych z zewnątrz. RCE daje możliwość uruchomienia kodu na urządzeniu.

Połączenie tych klas błędów z rolą bramy VPN tworzy ryzyko szersze niż awaria jednego appliance’u:

• dostęp do wewnętrznych usług zarządzających;
• manipulacja konfiguracją routingu lub uwierzytelniania;
• przechwycenie poświadczeń i tokenów TOTP;
• utrzymanie dostępu po aktualizacji przez zmodyfikowane pliki lub konfigurację;
• wykorzystanie zaufanej pozycji urządzenia do ruchu bocznego.

To nie oznacza, że każdy podatny SMA został przejęty. Oznacza, że przy potwierdzonym wykorzystaniu trzeba szukać dowodów zamiast zakładać ich brak.

IOC opublikowane przez SonicWall

Producent wskazuje kilka wzorców, które warto sprawdzić natychmiast:

• w extraweb_access.log: odpowiedź HTTP 200 dla żądań do /_api_/login lub /__api__/logout;
• w tym samym logu: żądania /wsproxy ze statusem 101 i podejrzanym parametrem hosta;
• w ctrl-service.log: wpisy „hotfix removal” zawierające nazwę ze ścieżką traversal;
• w /var/lib/unit/conf.json: nieoczekiwane trasy /__api__/login i /__api__/logout.

IOC należy traktować jako punkt startowy. Brak dokładnego ciągu nie wyklucza ataku, bo napastnik może zmienić ścieżkę, usunąć log lub użyć innej sekwencji. Rozszerz analizę o logowania administracyjne, eksporty konfiguracji, zmiany plików, nietypowe połączenia wychodzące i konta utworzone w okresie ekspozycji.

Patch czy pełny reimage

Jeżeli nie ma oznak kompromitacji i jakość telemetrii pozwala na wiarygodny wniosek, zaktualizuj urządzenie, sprawdź wersję i wykonaj testy funkcjonalne oraz bezpieczeństwa. Jeżeli IOC są obecne albo logi są niekompletne, bezpieczniejszą ścieżką jest reimage urządzenia fizycznego lub ponowne wdrożenie maszyny wirtualnej z zaufanego obrazu.

SonicWall zaleca przy potwierdzonych IOC również zmianę haseł użytkowników i administratorów oraz reset tokenów TOTP. To logiczne: odbudowa appliance’u nie unieważnia danych uwierzytelniających, które mogły zostać przechwycone wcześniej.

Kopia konfiguracji także wymaga oceny. Producent preferuje backup sprzed wskazanego okresu hotfixów, a gdy takiej kopii nie ma — dokładny audyt integralności. Przywrócenie niezweryfikowanej konfiguracji może odtworzyć mechanizm utrzymania dostępu.

Plan działania na 24 godziny

0–2 godziny

1. Zidentyfikuj wszystkie urządzenia SMA 1000, wersje i ekspozycję.
2. Zachowaj logi, konfigurację oraz obraz dysku przed zmianami.
3. Ogranicz dostęp administracyjny i zbędną publikację.
4. Rozpocznij wyszukiwanie IOC producenta.

2–8 godzin

1. Wdróż naprawioną wersję tam, gdzie nie ma przesłanek kompromitacji.
2. Odizoluj urządzenia z IOC i przygotuj reimage/redeploy.
3. Zresetuj sekrety, które mogły przechodzić przez przejęty system.
4. Sprawdź systemy docelowe dostępne z segmentu SMA.

8–24 godziny

1. Wykonaj test zdalnego dostępu, MFA, routingu i polityk autoryzacji.
2. Potwierdź, że wszystkie węzły mają wersję naprawioną.
3. Monitoruj nowe logowania, urządzenia i sesje zdalne.
4. Zapisz dowody oraz decyzję, dlaczego patch lub reimage był wystarczający.

Lekcja dla całej powierzchni dostępu

Internetowe bramy bezpieczeństwa są jednocześnie kontrolą i wartościowym celem. Powinny mieć osobny monitoring, minimalny dostęp zarządzający, niezależne kopie logów i ćwiczoną procedurę odbudowy. Jeżeli organizacja nie potrafi szybko postawić czystej bramy, incydent będzie trwał tak długo, jak analiza integralności starej.

Przegląd SMA warto połączyć z audytem bezpieczeństwa infrastruktury: sprawdzić segmentację, dostęp administracyjny, MFA, retencję logów i to, dokąd urządzenie może inicjować połączenia po stronie wewnętrznej.

Źródła pierwotne i urzędowe: SonicWall — SMA 1000 Series affected by multiple vulnerabilities, SonicWall PSIRT — SNWLID-2026-0008, Canadian Centre for Cyber Security — AV26-699.