Dwie nowe luki zero-day w SonicWall są już wykorzystywane. Zagrożone są systemy zdalnego dostępu firm

Firmowe bramy zdalnego dostępu ponownie znalazły się na celowniku cyberprzestępców. SonicWall 1 września 2026 roku ujawnił dwie nowe podatności w urządzeniach Secure Mobile Access 1000, a producent potwierdził, że obie są już wykorzystywane w rzeczywistych atakach. Pierwsza luka, CVE-2026-83548, otrzymała maksymalną ocenę 10,0 w skali CVSS i może zostać wykorzystana przez atakującego znajdującego się w internecie bez wcześniejszego logowania. Druga, CVE-2026-83549, umożliwia wykonanie poleceń systemu operacyjnego. Badacze bezpieczeństwa wskazują, że połączenie obu błędów może doprowadzić do zdalnego wykonywania kodu bez posiadania prawidłowych danych uwierzytelniających.

Sytuacja jest szczególnie poważna ze względu na rolę urządzeń SMA1000. Nie są to zwykłe serwery stojące głęboko w firmowej sieci, lecz bramy umieszczane na jej krawędzi, których zadaniem jest umożliwianie pracownikom i partnerom zdalnego dostępu do wewnętrznych aplikacji. Z natury muszą więc być osiągalne z internetu. Przejęcie takiego urządzenia może dać napastnikowi dogodny punkt wyjścia do dalszego przemieszczania się po infrastrukturze przedsiębiorstwa. CISA już 2 września dodała obie podatności do katalogu Known Exploited Vulnerabilities, co potwierdza, że zagrożenie nie jest teoretyczne.

Jakie dwie nowe luki zero-day wykryto w SonicWall SMA1000?

Pierwsza podatność to CVE-2026-83548 występująca w interfejsie Appliance Work Place. SonicWall opisuje ją jako błąd typu server-side request forgery, czyli SSRF, związany z niezamierzoną alternatywną ścieżką dostępu i mechanizmem proxy. W praktyce odpowiednio przygotowane żądanie może doprowadzić do sytuacji, w której urządzenie wykonuje operacje lub komunikuje się z zasobami, do których użytkownik z internetu normalnie nie powinien mieć dostępu. Najbardziej niepokojące jest to, że atak nie wymaga wcześniejszego uwierzytelnienia. Właśnie dlatego luka otrzymała krytyczną ocenę CVSS 10,0.

Drugi błąd, CVE-2026-83549, znajduje się w Appliance Management Console i został oceniony na 7,8 w skali CVSS. Jest to podatność typu OS command injection, pozwalająca w określonych warunkach na wykonanie arbitralnych poleceń systemu operacyjnego. Samodzielnie wymaga ona dostępu administratora, ale nie należy analizować jej w oderwaniu od pierwszej luki. Rapid7 wskazuje, że wykorzystanie CVE-2026-83548 może potencjalnie stworzyć dostęp potrzebny do uruchomienia drugiej podatności. W efekcie dwie pozornie różne luki mogą utworzyć jeden łańcuch prowadzący do zdalnego wykonania kodu.

Dlaczego połączenie CVE-2026-83548 i CVE-2026-83549 jest tak niebezpieczne?

Wiele podatności o wysokiej ocenie nie może zostać wykorzystanych bez spełnienia dodatkowych warunków, na przykład posiadania konta administratora. Na papierze CVE-2026-83549 również wygląda właśnie w ten sposób. Problem pojawia się jednak wtedy, gdy atakujący wykorzystuje pierwszą lukę do obejścia bariery, która normalnie chroniłaby dostęp do wrażliwych funkcji. SSRF może pozwolić urządzeniu potraktować zewnętrzne żądanie w sposób podobny do komunikacji pochodzącej z bardziej zaufanego środowiska. Następnie podatność command injection daje możliwość przejścia od dostępu do wykonania poleceń.

Takie łańcuchy są jednym z najbardziej niebezpiecznych scenariuszy w cyberbezpieczeństwie. Każda luka osobno może mieć określone ograniczenia, ale razem pozwalają ominąć kolejne warstwy ochrony. Rapid7 ocenia, że najnowsza para błędów może prowadzić do nieuwierzytelnionego RCE, czyli wykonania kodu przez atakującego, który nie musi wcześniej posiadać legalnego konta. SonicWall nie opublikował pełnego technicznego opisu bieżących ataków, dlatego nie należy zakładać, że każdy szczegół łańcucha jest już publicznie znany. Sam producent potwierdził jednak aktywne wykorzystanie opisanych podatności.

Które urządzenia SonicWall są zagrożone nowymi lukami zero-day?

Nowe podatności dotyczą serii SonicWall SMA1000, a konkretnie modeli 6210, 7210 oraz wirtualnego 8200v działającego na obsługiwanych hypervisorach. W gałęzi 12.4.3 podatne są systemy z platform-hotfix 12.4.3-03453 oraz wcześniejsze. W gałęzi 12.5.0 problem dotyczy wersji 12.5.0-02835 oraz wcześniejszych. SonicWall przygotował poprawione wydania 12.4.3-03526 i 12.5.0-02952. Producent nie przedstawia aktualizacji jako opcjonalnego działania wykonywanego podczas najbliższego okna serwisowego, lecz zdecydowanie zaleca natychmiastowe przejście na aktualny hotfix.

Ważne jest również to, czego bieżący alert nie dotyczy. Według informacji SonicWall podatności są niezależne od problemów występujących w innych produktach producenta. Doniesienia dotyczą serii SMA1000, a nie wszystkich urządzeń SonicWall wykorzystujących funkcje VPN. Dostępne informacje wskazują również, że problem nie obejmuje linii SMA 100 ani funkcji SSL-VPN działających na klasycznych firewallach SonicWall. Administrator powinien więc najpierw ustalić dokładny model urządzenia i zainstalowaną wersję oprogramowania, zamiast zakładać, że każda brama tej marki jest podatna na tę konkretną parę błędów.

Dlaczego urządzenia do zdalnego dostępu są szczególnie atrakcyjnym celem dla cyberprzestępców?

Bramy VPN i systemy Secure Mobile Access znajdują się w bardzo dogodnym dla atakującego miejscu. Muszą przyjmować połączenia z internetu, a jednocześnie posiadają dostęp do zasobów znajdujących się po drugiej stronie firmowej granicy bezpieczeństwa. Ich przejęcie może więc oznaczać ominięcie części zabezpieczeń, które normalnie chronią stacje robocze czy serwery przed bezpośrednim dostępem z sieci publicznej. Rapid7 zwraca uwagę, że interfejs Work Place urządzeń SMA1000 może być wystawiony do internetu w ramach normalnej konfiguracji, ponieważ właśnie na tym polega funkcja zdalnego dostępu.

Dodatkowym problemem jest poziom zaufania, jakim urządzenia tego typu cieszą się wewnątrz organizacji. Przepływa przez nie ruch użytkowników, informacje o uwierzytelnieniu i połączenia do wewnętrznych aplikacji. Jeśli napastnik zdoła przejąć bramę, może próbować wykorzystać ją jako punkt obserwacyjny albo miejsce rozpoczęcia dalszej penetracji. W lipcowym incydencie dotyczącym wcześniejszych luk SMA1000 badacze Volexity obserwowali już między innymi próby przechodzenia z przejętego urządzenia do innych systemów w sieci klienta oraz analizowanie ruchu LDAP w poszukiwaniu danych uwierzytelniających. Nowych wrześniowych ataków nie należy automatycznie przypisywać temu samemu sprawcy, ale wcześniejszy przypadek pokazuje potencjalne konsekwencje kompromitacji takiej bramy.

Co oznacza określenie zero-day w przypadku najnowszych luk SonicWall?

Zero-day nie oznacza po prostu bardzo poważnej podatności. Termin opisuje sytuację, w której błąd był wykorzystywany przez napastników zanim użytkownicy otrzymali publiczną informację i możliwość standardowego zabezpieczenia się poprzez dostępny patch. SonicWall poinformował o CVE-2026-83548 i CVE-2026-83549 1 września, ale jednocześnie potwierdził, że jego zespół PSIRT analizował przypadek wskazujący na aktywne wykorzystanie luk. Administratorzy dowiedzieli się więc o problemie już w sytuacji, gdy ktoś próbował wykorzystywać go przeciwko rzeczywistym urządzeniom.

To zasadniczo zmienia sposób reagowania. Przy zwykłej podatności organizacja może zainstalować aktualizację i uznać, że zamknęła problem zanim nastąpił atak. W przypadku zero-day wykorzystanego przed ujawnieniem samo zainstalowanie poprawki nie odpowiada na pytanie, czy urządzenie nie zostało wcześniej przejęte. Z tego powodu zarówno SonicWall, jak i Rapid7 podkreślają potrzebę sprawdzenia potencjalnych oznak kompromitacji. Aktualizacja blokuje przyszłe wykorzystanie poprawionych błędów, ale nie usuwa automatycznie backdoora lub innych zmian pozostawionych przez atakującego przed instalacją hotfixa.

Czy CISA potwierdziła, że nowe podatności SonicWall są rzeczywiście wykorzystywane?

Tak. 2 września 2026 roku obie luki znalazły się w katalogu Known Exploited Vulnerabilities amerykańskiej agencji CISA. Trafiają do niego podatności, dla których istnieją wiarygodne dowody aktywnego wykorzystywania. Wpis dla CVE-2026-83548 potwierdza, że jest to SSRF pozwalający nieautoryzowanemu użytkownikowi uzyskać dostęp do wrażliwych funkcji. Analogiczny wpis dotyczący CVE-2026-83549 opisuje możliwość wykonania poleceń systemu operacyjnego. CISA określiła również niezwykle krótki termin wymaganej reakcji dla objętych dyrektywą amerykańskich instytucji federalnych - 5 września 2026 roku.

Krótki termin ma szczególne znaczenie, ponieważ obecne podejście CISA do najbardziej ryzykownych luk internetowych obejmuje nie tylko instalowanie poprawek, ale również wymagania dotyczące forensic triage. Przy CVE-2026-83548 katalog wskazuje wprost konieczność analizy śledczej zgodnie z BOD 26-04. Jest to logiczne w sytuacji, gdy podatny system pełni rolę bramy do organizacji i ataki rozpoczęły się przed opublikowaniem informacji o błędzie. Dla prywatnych przedsiębiorstw amerykańska dyrektywa nie jest formalnym obowiązkiem, ale sam fakt tak szybkiego umieszczenia luk w KEV powinien być traktowany jako bardzo mocny sygnał priorytetu.

Czy wystarczy zainstalować poprawkę SonicWall, żeby firma była już bezpieczna?

Nie zawsze. Aktualizacja jest pierwszym i koniecznym krokiem, ale w przypadku urządzenia dostępnego z internetu podczas trwania kampanii zero-day należy dodatkowo odpowiedzieć na pytanie, czy zostało ono wcześniej wykorzystane. Rapid7 wyraźnie ostrzega, że organizacje nie powinny polegać wyłącznie na patchowaniu jako dowodzie braku kompromitacji. Jeśli urządzenie działało na podatnej wersji i było publicznie osiągalne, trzeba potraktować je również jako przedmiot dochodzenia.

SonicWall zaleca klientom skontaktowanie się z pomocą techniczną producenta w celu sprawdzenia systemu pod kątem wskaźników kompromitacji. Jeżeli zostaną znalezione, zalecenia idą znacznie dalej niż aktualizacja. Fizyczne urządzenie powinno zostać ponownie przygotowane z czystego obrazu, a środowisko wirtualne ponownie wdrożone. Producent rekomenduje również zmianę wszystkich haseł użytkowników i administratorów oraz reset tokenów TOTP. Tak szeroka reakcja pokazuje, że potencjalne przejęcie bramy dostępu należy traktować jak incydent dotyczący poświadczeń i całej granicy bezpieczeństwa organizacji.

Dlaczego po wykryciu włamania trzeba zmienić hasła i zresetować TOTP?

Jeżeli atakujący uzyska wystarczająco wysoki poziom kontroli nad systemem pośredniczącym w uwierzytelnianiu użytkowników, istnieje ryzyko, że samo usunięcie podatności nie odbierze mu wszystkich zdobytych możliwości. Mógł wcześniej przechwycić hasło, token sesyjny, informacje o kontach albo ustanowić alternatywny sposób wejścia. Zmiana poświadczeń ma więc odciąć materiały uwierzytelniające, które potencjalnie zostały ujawnione podczas wcześniejszej obecności napastnika. Właśnie dlatego rekomendacja SonicWall obejmuje zarówno konta zwykłych użytkowników, jak i administratorów.

Reset TOTP jest równie ważny. Wieloskładnikowe uwierzytelnianie bardzo dobrze ogranicza skuteczność wielu ataków, ale nie powinno być traktowane jako magiczna ochrona po przejęciu urządzenia uczestniczącego w całym procesie dostępu. Jeżeli organizacja ma wiarygodne dowody kompromitacji, bezpieczniej jest uznać dotychczasowe sekrety TOTP za potencjalnie zagrożone i wygenerować je ponownie. Nie oznacza to, że producent potwierdził masową kradzież kodów MFA w bieżących wrześniowych atakach. Jest to procedura ograniczająca ryzyko wynikające z faktu, że nie zawsze można ustalić każdy element aktywności napastnika na przejętym urządzeniu.

Dlaczego to już kolejny poważny incydent dotyczący SonicWall SMA1000 w 2026 roku?

Najbardziej niepokojącym elementem obecnej sytuacji jest to, że we wrześniu nie mamy do czynienia z pierwszą podobną historią. W lipcu SonicWall załatał wcześniejsze zero-daye CVE-2026-15409 i CVE-2026-15410. Schemat był zaskakująco podobny: krytyczna luka SSRF bez uwierzytelnienia oraz podatność pozwalająca na wykonanie poleceń w konsoli zarządzającej. Tamte problemy również zostały wykorzystane przed publicznym ujawnieniem. Co szczególnie istotne, aktualizacje wydane w lipcu nie chronią automatycznie przed nową parą CVE z września - są to odrębne podatności wymagające kolejnego hotfixa.

Poprzedni incydent dostarczył również znacznie więcej informacji o działaniach atakujących. Volexity badało włamania prowadzone przez grupę oznaczoną jako UTA0533, która po przejęciu urządzeń instalowała między innymi komponenty określane nazwami KNUCKLEBALL i ORANGETAIL. Atakujący tworzyli webshell, wykorzystywali przejętą bramę jako proxy i próbowali przemieszczać się dalej po sieci. Tych konkretnych narzędzi ani sprawcy nie należy jednak przypisywać nowej wrześniowej kampanii. Na początku września SonicWall nie opublikował publicznej atrybucji bieżących ataków.

Czy administrator może łatwo sprawdzić, czy SonicWall SMA1000 został zaatakowany?

Problem polega na tym, że w momencie ujawnienia nowych podatności nie opublikowano kompletnego publicznego zestawu wskaźników kompromitacji dla bieżącej kampanii. Rapid7 informował 3 września, że nie zidentyfikowano publicznie dostępnego proof-of-conceptu, nowych IoC ani atrybucji dotyczącej aktywnego wykorzystywania CVE-2026-83548 i CVE-2026-83549. SonicWall kieruje więc administratorów do swojego wsparcia technicznego w celu pomocy przy przeglądzie urządzeń.

Brak publicznego IoC nie oznacza jednak, że firma powinna czekać. W pierwszej kolejności trzeba ustalić wersję oprogramowania, internetową ekspozycję urządzenia i okres, przez który działało ono na podatnym buildzie. Następnie warto przeanalizować nietypowe logowania administracyjne, nowe konta, nieoczekiwane modyfikacje konfiguracji, połączenia wychodzące i próby komunikacji z systemami wewnętrznymi. W przypadku urządzeń brzegowych monitoring powinien obejmować również ruch za bramą, ponieważ pierwszym widocznym sygnałem włamania może być nie sam exploit, lecz późniejsza próba ruchu bocznego.

Dlaczego przejęcie VPN może prowadzić do ataku ransomware na całą firmę?

Ransomware bardzo często potrzebuje punktu wejścia, który pozwoli przestępcom dotrzeć do wewnętrznych kont i systemów. Luka na publicznie dostępnym urządzeniu VPN może być do tego idealnym narzędziem. Po przejęciu bramy napastnik może próbować pozyskać dodatkowe poświadczenia, rozpoznać strukturę sieci, dotrzeć do Active Directory, serwerów plików czy systemów kopii zapasowych. Dopiero później następuje właściwa faza szyfrowania i wymuszenia. Z tego powodu podatność na urządzeniu zdalnego dostępu powinna być traktowana inaczej niż błąd w aplikacji działającej na pojedynczym komputerze użytkownika.

W przypadku nowych wrześniowych CVE CISA oznacza wykorzystanie w kampaniach ransomware jako nieznane. Nie ma więc podstaw, żeby twierdzić, że CVE-2026-83548 lub CVE-2026-83549 są już wykorzystywane przez konkretną grupę ransomware. Historia wcześniejszych podatności w urządzeniach brzegowych pokazuje jednak, dlaczego organy bezpieczeństwa reagują tak szybko. Czas od ujawnienia luki do jej masowego wykorzystywania może dziś być bardzo krótki, a w tym przypadku faza eksploatacji rozpoczęła się jeszcze przed publicznym ostrzeżeniem.

Ile urządzeń SonicWall SMA1000 jest dostępnych bezpośrednio z internetu?

Według danych przywoływanych przez BleepingComputer organizacja Shadowserver obserwowała na początku września ponad 400 urządzeń SMA1000 widocznych z internetu. Nie oznacza to, że wszystkie były podatne - część mogła już posiadać najnowsze poprawki - ale liczba pokazuje realną powierzchnię ataku. W przypadku bramy VPN sama internetowa ekspozycja nie jest błędem konfiguracyjnym, ponieważ urządzenie musi być dostępne dla pracowników znajdujących się poza organizacją. Problem polega na tym, że każdy błąd przed uwierzytelnieniem staje się wtedy osiągalny również dla atakującego.

W praktyce właśnie dlatego napastnicy coraz częściej koncentrują się na urządzeniach edge. Firewall, VPN, appliance do transferu plików czy gateway pocztowy działa często przez całą dobę i nie może zostać łatwo schowany za kolejną warstwą ochrony. Wiele takich systemów nie posiada również tak rozbudowanych narzędzi EDR jak standardowe serwery Windows czy Linux. Jeśli przestępca potrafi utrzymać się bezpośrednio na appliance, jego aktywność może pozostawać mniej widoczna dla zespołu SOC. Najskuteczniejszą obroną staje się więc bardzo szybkie patchowanie połączone z dobrym monitoringiem urządzeń brzegowych.

Czy odłączenie interfejsu zarządzającego od internetu rozwiązuje problem?

Ograniczanie dostępu do interfejsów administracyjnych jest bardzo dobrą praktyką, ale nie zastępuje aktualizacji w tym konkretnym przypadku. Pierwsza luka znajduje się w Appliance Work Place, czyli komponencie wykorzystywanym do zapewniania zdalnego dostępu użytkownikom i często z założenia wystawionym do internetu. Nie jest to więc wyłącznie scenariusz, w którym firma przypadkowo pozostawiła otwarty publicznie panel administratora. Atak rozpoczyna się od powierzchni, która może być publiczna z powodów funkcjonalnych.

Z drugiej strony warto wykorzystać obecny incydent do ponownej oceny całej architektury. Interfejsy administracyjne powinny być dostępne tylko z określonych sieci zarządzających, a konta uprzywilejowane objęte silnym MFA i zasadą najmniejszych uprawnień. Dostęp z urządzenia VPN do wewnętrznych segmentów również powinien być ograniczony do niezbędnego minimum. Dzięki segmentacji nawet przejęcie bramy nie powinno automatycznie oznaczać możliwości komunikacji ze wszystkimi serwerami w organizacji. Patch usuwa konkretny błąd, natomiast dobra architektura ogranicza skutki kolejnego, którego producent jeszcze nie zna.

Jak firmy powinny zareagować na nowe zero-daye SonicWall krok po kroku?

Pierwszym zadaniem jest inwentaryzacja. Organizacja powinna ustalić, czy posiada modele SMA 6210, 7210 lub 8200v oraz jaką wersję platform-hotfix wykorzystują. Jeżeli jest to 12.4.3-03453 lub starsza albo 12.5.0-02835 lub starsza, urządzenie należy natychmiast zaktualizować odpowiednio do 12.4.3-03526 lub 12.5.0-02952 albo nowszego wydania wskazanego przez producenta. Nie należy przy tym zakładać, że lipcowy hotfix nadal wystarcza - nowe luki wymagają aktualnej wrześniowej wersji.

Drugim etapem powinna być analiza ewentualnego wcześniejszego włamania. Jeżeli pojawią się oznaki kompromitacji, SonicWall rekomenduje re-image urządzenia fizycznego albo ponowne wdrożenie appliance wirtualnego, rotację wszystkich haseł użytkowników i administratorów oraz reset TOTP. Równolegle należy przejrzeć aktywność w sieci wewnętrznej pod kątem prób lateral movement i nietypowych uwierzytelnień. Warto również zachować potrzebne logi i inne dane przed odtworzeniem urządzenia, aby nie zniszczyć materiału przydatnego podczas analizy incydentu.

Czy MFA ochroni firmę przed wykorzystaniem CVE-2026-83548 i CVE-2026-83549?

Nie należy na to liczyć. MFA jest niezwykle skuteczne przeciwko atakom wykorzystującym wykradzione hasła, ale CVE-2026-83548 może zostać zaatakowane przed uwierzytelnieniem. Innymi słowy, przestępca nie musi rozpoczynać od próby zalogowania się na konto pracownika. Próbuje wykorzystać błąd w samym urządzeniu. Jeśli następnie uda się połączyć go z podatnością command injection, system bezpieczeństwa oparty na sprawdzaniu hasła i drugiego składnika może w ogóle nie być pierwszą barierą, z którą spotyka się atakujący.

MFA nadal pozostaje jednak bardzo ważne dla ograniczania dalszych skutków incydentu. Jeśli atakujący pozyska pojedyncze hasło albo spróbuje wykorzystać konto w innym systemie, dodatkowy składnik uwierzytelniający może go zatrzymać. Różnica polega na tym, że organizacja musi stosować ochronę warstwową. Aktualizacje zabezpieczają appliance, MFA chroni tożsamości, segmentacja ogranicza możliwość ruchu bocznego, a monitoring pomaga wykrywać nietypowe zachowanie. Żaden z tych mechanizmów nie jest samodzielnym zamiennikiem dla pozostałych.

Dlaczego kolejne zero-daye w systemach zdalnego dostępu są problemem większym niż jeden produkt SonicWall?

Najważniejsza lekcja nie dotyczy wyłącznie SonicWall. Urządzenia VPN, firewalle, load balancery i bramy zdalnego dostępu stały się jednym z najatrakcyjniejszych celów dla wyspecjalizowanych grup przestępczych i szpiegowskich. Tradycyjnie przedsiębiorstwa koncentrowały największą część ochrony na komputerach użytkowników. Tymczasem przejęcie urządzenia stojącego przed tymi komputerami może pozwolić ominąć wiele mechanizmów endpoint security. Brama sieciowa jest jednocześnie zawsze dostępna i często posiada szerokie uprawnienia komunikacyjne.

Dlatego procedura aktualizowania urządzeń brzegowych nie może wyglądać tak samo jak aktualizacja mniej istotnego wewnętrznego serwera. Firma powinna znać wszystkie publicznie dostępne appliance, automatycznie śledzić ich wersje i mieć procedurę pozwalającą instalować krytyczne poprawki w ciągu godzin, a nie tygodni. Przypadek SMA1000 pokazuje dodatkowo, że instalacja jednej poprawki nie kończy problemu na zawsze. Po lipcowej parze aktywnie wykorzystywanych zero-dayów we wrześniu pojawiła się kolejna, podobna para. Bez ciągłego monitoringu łatwo więc pozostać z fałszywym przekonaniem, że urządzenie zostało zabezpieczone miesiąc wcześniej.

Co nowe luki SonicWall oznaczają dla firm korzystających ze zdalnej pracy?

Dla użytkownika końcowego prawdopodobnie niewiele się zmieni. Nadal uruchomi klienta VPN albo portal zdalnego dostępu i połączy się z aplikacją firmową. Dla administratora sytuacja jest znacznie poważniejsza. Infrastruktura umożliwiająca pracę spoza biura jest jednocześnie częścią powierzchni ataku organizacji. Każde przedsiębiorstwo, które posiada podatny SMA1000, powinno potraktować najnowszy komunikat jako incydent o wysokim priorytecie, a nie jako rutynowy biuletyn producenta.

Najważniejsza różnica pomiędzy zwykłą podatnością a sytuacją z początku września 2026 roku jest prosta: napastnicy nie czekali, aż firmy zaplanują aktualizację. SonicWall potwierdził wykorzystanie CVE-2026-83548 i CVE-2026-83549 już w momencie publikacji ostrzeżenia, a CISA dzień później umieściła obie luki w katalogu KEV. Firmy korzystające z zagrożonych wersji powinny więc nie tylko zainstalować poprawki, lecz również założyć możliwość wcześniejszej próby włamania. W przypadku urządzenia będącego jednym z głównych wejść do firmowej sieci ostrożność po instalacji patcha jest równie ważna jak szybkość samej aktualizacji.