MSI RadiX AXE6600: 11 krytycznych luk command injection prowadzi do roota

9 sierpnia 2026 roku w polskiej strefie czasowej opublikowano serię 11 rekordów CVE dotyczących routera MSI RadiX AXE6600. Wszystkie opisują ten sam niebezpieczny wzorzec: dane z interfejsu zarządzania trafiają do polecenia systemowego bez właściwej neutralizacji. Według ocen CNA atak sieciowy nie wymaga uwierzytelnienia ani działania użytkownika, a skutkiem może być wykonanie kodu z uprawnieniami root.

To nie jest jedenaście wariantów jednego parametru w pojedynczym formularzu. Rekordy obejmują WPS, filtrowanie adresów URL i MAC, kontrolę dostępu, DMZ, ALG, przekierowanie i wyzwalanie portów, konfigurację SSH oraz Telnetu, a także OpenVPN. Szerokość listy sugeruje problem z architekturą obsługi konfiguracji, nie tylko przeoczenie w jednej funkcji.

Co dokładnie opublikowano

Rekordy CNA pojawiły się między 23:10 UTC 8 sierpnia a 00:00 UTC 9 sierpnia, czyli między 01:10 a 02:00 CEST 9 sierpnia w Polsce. Zakres tworzą:

CVE	Powierzchnia wejścia
CVE-2026-71983	`wps.cgi`, parametry PIN dla pasm 2,4/5/6 GHz
CVE-2026-71984	filtrowanie URL
CVE-2026-71985	kontrola dostępu
CVE-2026-71986	konfiguracja DMZ
CVE-2026-71987	ustawienia ALG
CVE-2026-71988	przekierowanie portów
CVE-2026-71989	port triggering
CVE-2026-71990	konfiguracja SSH
CVE-2026-71991	konfiguracja Telnetu
CVE-2026-71992	filtrowanie MAC
CVE-2026-71993	konfiguracja OpenVPN

CVE-2026-71983 i pozostałe rekordy wskazują firmware do wersji v781521 włącznie. CNA VulnCheck przyznał każdej luce 9,8 w CVSS 3.1 oraz 9,3 w CVSS 4.0. Wektor zakłada dostęp sieciowy, niską złożoność, brak wymaganych uprawnień i brak interakcji użytkownika. Ostatni rekord serii, CVE-2026-71993, dotyczy funkcji OpenVPN.

Dlaczego command injection w routerze jest tak groźne

Interfejs webowy urządzenia często nie implementuje całej logiki sieciowej samodzielnie. Odbiera ustawienie, zapisuje je, a następnie wywołuje narzędzie systemowe lub skrypt, który modyfikuje firewall, usługę VPN albo konfigurację radia. Jeżeli aplikacja składa taką komendę jako tekst i dołącza niezweryfikowaną wartość, dane mogą zmienić znaczenie polecenia.

Walidacja po stronie przeglądarki nie jest kontrolą bezpieczeństwa: klient HTTP może wysłać żądanie bez formularza. Sama lista zakazanych znaków również bywa zawodna, ponieważ shell, kodowanie, różne ścieżki parsowania i narzędzia pomocnicze mają odmienne reguły. Bezpieczniejszy projekt nie uruchamia powłoki, przekazuje argumenty przez API procesowe, stosuje ścisłe allowlisty wartości i wykonuje operację z minimalnymi uprawnieniami.

Na routerze przejęcie procesu uprzywilejowanego daje pozycję przy całym ruchu lokalnej sieci. Napastnik może zmieniać DNS, reguły NAT i firewalla, tworzyć trwały dostęp, obserwować metadane połączeń albo kierować użytkowników do fałszywych usług. CVE potwierdzają możliwość wykonania poleceń i uzyskania roota; konkretne działania po przejęciu są oceną możliwego wpływu, nie informacją o zaobserwowanej kampanii.

Kto jest narażony

Bezpośrednio zagrożone są urządzenia RadiX AXE6600 z firmware v781521 lub starszym. Priorytet gwałtownie rośnie, gdy panel zarządzania jest osiągalny z Internetu, sieci gościnnej, Wi-Fi dla urządzeń IoT albo z niezaufanej części LAN. Wysoki wynik bazowy nie oznacza jednak automatycznie, że każdy egzemplarz jest publicznie dostępny.

Administrator powinien rozróżnić trzy pytania:

Czy wskazany model i wersja rzeczywiście pracują w środowisku?
Z jakich segmentów można połączyć się z interfejsem administracyjnym?
Czy urządzenie mogło zostać zmodyfikowane przed ograniczeniem dostępu?

Nie wystarczy wyszukać nazwę modelu w spisie zakupów. Warto potwierdzić wersję na urządzeniu, jego rolę, adresy zarządzające, reguły publikacji, zdalne usługi i kopię konfiguracji. Router domowy używany do pracy zdalnej także może chronić dostęp do zasobów firmowych, więc nie powinien automatycznie wypadać z inwentaryzacji ryzyka.

Co zrobić teraz

Strona wsparcia MSI dla RadiX AXE6600 jest właściwym miejscem do sprawdzania firmware. W chwili publikacji rekordy CVE nie wskazują jednoznacznie pierwszej bezpiecznej wersji, dlatego nie należy zgadywać, że sam ponowny flash tej samej wersji usuwa błąd.

Zablokuj panel administracyjny od strony WAN i wyłącz nieużywane mechanizmy zdalnego zarządzania.
Ogranicz dostęp do osobnego, zaufanego segmentu lub jednego hosta administracyjnego.
Wyłącz Telnet i funkcje, których organizacja nie używa; nie jest to pełna naprawa wspólnego błędu, ale zmniejsza powierzchnię.
Sprawdź u MSI dostępność firmware nowszego niż zakres oznaczony jako podatny i zachowaj kopię numeru wersji oraz sumy pliku.
Przejrzyj konfigurację DNS, przekierowań, DMZ, VPN, kont administratorów i reguł firewalla pod kątem nieautoryzowanych zmian.
Jeżeli panel był publiczny lub dostępny z niezaufanego segmentu, potraktuj aktualizację jako początek dochodzenia, nie jego koniec.
Po przywróceniu z zaufanego obrazu zmień sekrety, które mogły przechodzić przez urządzenie lub służyć do jego administracji.

Jak ustalić priorytet bez polegania wyłącznie na CVSS

Wynik 9,8 uzasadnia pilną reakcję, ale kolejność działań w większej flocie powinna wynikać z osiągalności i roli urządzenia. Najpierw utwórz macierz zawierającą wersję firmware, segment źródłowy mający dostęp do panelu, funkcję routera, rodzaj przechodzącego ruchu oraz możliwość odtworzenia. Egzemplarz wystawiony do Internetu i obsługujący VPN pracowników ma inny profil niż identyczny model odłączony w magazynie, choć skaner przypisze im ten sam CVSS.

Praktyczna priorytetyzacja może użyć czterech poziomów. Poziom pierwszy to panel osiągalny publicznie albo z sieci, w której działają niezarządzane urządzenia. Poziom drugi obejmuje routery dostępne z szerokiej sieci użytkowników lub IoT. Poziom trzeci to interfejs ograniczony do VLAN-u administracyjnego, ale bez dodatkowego filtrowania hostów. Poziom czwarty obejmuje urządzenia wyłączone, zapasowe lub fizycznie odseparowane. Wszystkie podatne wersje wymagają naprawy; poziom określa jedynie kolejność i intensywność dochodzenia.

Warto też sprawdzić, czy reguły ochronne są egzekwowane przed routerem, czy przez sam podatny router. Lista ACL skonfigurowana w urządzeniu może zostać zmieniona po uzyskaniu roota. Zewnętrzna zapora albo dedykowana sieć zarządzająca daje niezależną warstwę. To samo dotyczy logów: jeśli jedyna kopia znajduje się na urządzeniu, napastnik uprzywilejowany może ją zmodyfikować. Wysyłanie zdarzeń do zewnętrznego kolektora zwiększa szansę zachowania osi czasu.

Czego powinna dowodzić walidacja po aktualizacji

Zamknięcie zadania nie powinno polegać na zrzucie ekranu z nowym numerem firmware. Dowód naprawy obejmuje numer wersji odczytany po restarcie, źródło obrazu, sumę pliku, datę instalacji oraz test osiągalności interfejsu z WAN, sieci gościnnej, IoT i zwykłego segmentu użytkowników. Osobno trzeba potwierdzić, że Telnet pozostaje wyłączony, SSH używa oczekiwanej konfiguracji, a lista administratorów i kluczy jest poprawna.

Jeżeli producent nie opublikował jeszcze wersji jednoznacznie oznaczonej jako bezpieczna, raport powinien nazywać stan „zmitygowanym”, a nie „naprawionym”. Właściciel ryzyka musi mieć datę ponownej kontroli i warunek zamknięcia: oficjalną wersję poza podatnym zakresem, jej instalację oraz ponowny test segmentacji. Taka dokumentacja zapobiega sytuacji, w której tymczasowa blokada WAN po kilku tygodniach znika podczas innej zmiany konfiguracji.

Detekcja i odzyskanie zaufania

Szukaj zmian konfiguracji bez odpowiadającego im zgłoszenia, nowych reguł NAT, nietypowych serwerów DNS, włączonych usług administracyjnych, połączeń wychodzących inicjowanych przez router i restartów w nietypowych porach. Zestaw logi urządzenia z DHCP, DNS, firewalla brzegowego i systemu zarządzania. Brak alarmu EDR na routerze nie jest dowodem braku kompromitacji.

Jeżeli integralności firmware lub konfiguracji nie da się wiarygodnie potwierdzić, bezpieczniejszą ścieżką jest odtworzenie urządzenia z obrazu pobranego z oficjalnego kanału, ręczne odtworzenie zweryfikowanej konfiguracji i ponowne sprawdzenie ekspozycji. Import starego backupu bez analizy może przywrócić złośliwe ustawienia.

Fakty a wnioski Breachroad

Faktem jest publikacja 11 rekordów, wskazanie wersji do v781521, zdalnego wektora bez uwierzytelnienia i wpływu prowadzącego do roota. Publiczne rekordy nie potwierdzają masowego wykorzystywania ani nie podają kompletnej telemetrii ataku.

Wniosek Breachroad: tak szeroki zestaw podatnych funkcji należy traktować jako awarię granicy między panelem webowym a uprzywilejowanym systemem operacyjnym. Szkolenia techniczne z cyberbezpieczeństwa powinny uczyć zespoły oceny realnej ekspozycji, a audyt bezpieczeństwa IT może zweryfikować segmentację, płaszczyznę zarządzania i zdolność do bezpiecznego odtworzenia urządzeń brzegowych.