Stan informacji: 2 listopada 2026 r. CVE-2026-98432 to podatność w obsłudze połączeń TCP w jądrze Linux. Może pozwolić na zdalny atak bez konta na serwerze i bez działania użytkownika. Red Hat ocenia ją obecnie jako krytyczną, z wynikiem CVSS 3.1 9,8/10. Dla administratorów oznacza to potrzebę pilnego sprawdzenia kerneli oraz dostępności poprawek dla konkretnych systemów. Karta CVE Red Hat.

Temat opisał The Hacker News. Poniżej przedstawiamy własne omówienie dla zespołów utrzymujących serwery, aplikacje i klastry Kubernetes, uzupełnione o późniejsze komunikaty producentów.

Co dzieje się w jądrze Linux

Błąd jest związany z równoczesną obsługą połączenia TCP przez różne rdzenie procesora. Przy tworzeniu nowego gniazda jądro przekazuje mu strukturę opcji IPv4. Inny rdzeń może w tym samym czasie nadal korzystać z tej struktury, odpowiadając na ponowione żądanie połączenia. Jeżeli pamięć zostanie wcześniej zwolniona, powstaje use-after-free, czyli odwołanie do pamięci, która przestała należeć do danego obiektu.

Poprawka odracza zwolnienie pamięci do momentu zakończenia jej odczytu przez pozostałych użytkowników mechanizmu RCU. Opis obejmuje także pokrewny problem migracji gniazd. Pierwszy z tych mechanizmów nie dotyczy IPv6, które kopiuje opcje; opis wskazuje jednak osobny przypadek migracji IPv6 wymagający odrębnej poprawki. Nie należy z tego wyciągać ogólnego wniosku, że każda konfiguracja IPv6 jest bezpieczna. Opis techniczny w trackerze Debiana.

Zdalne wykonanie kodu: co faktycznie pokazano

Anthropic poinformował o demonstracji ataku na serwer Linux udostępniający gniazdo nasłuchujące Multipath TCP, czyli MPTCP. Według firmy exploit uzyskał możliwość uruchamiania poleceń jako root bez uwierzytelnienia. Najpierw wykorzystał wyciek informacji do obejścia losowania adresów pamięci jądra, a następnie doprowadził do przejęcia sterowania.

W opisanym teście pierwszy etap zajął 48 minut, a drugi kolejne pięć. To wynik konkretnego eksperymentu, a nie prognoza czasu przejęcia dowolnego serwera. Publikacja nie podaje kompletnej konfiguracji testowego kernela ani kodu exploita. Demonstracja badawcza nie jest też sama w sobie dowodem wykorzystania luki w atakach na firmy. Raport Anthropic, sekcja dotycząca Linuxa.

MPTCP i Go: brak świadomej konfiguracji nie wystarcza

Go Security Team zwraca uwagę, że od Go 1.24 programy domyślnie włączają MPTCP dla gniazd nasłuchujących w Linuksie. Dlatego przegląd powinien objąć także usługi napisane w Go, nawet jeśli administrator nie wdrażał MPTCP jako osobnego projektu.

Zespół Go wskazuje możliwość ustawienia GODEBUG=multipathtcp=0 w środowisku procesu. To zmiana domyślnego zachowania aplikacji, którą trzeba wdrożyć wraz z jej ponownym uruchomieniem. Jawne wywołanie SetMultipathTCP w kodzie może nadpisać to ustawienie.

Wyłączenie MPTCP nie jest potwierdzeniem usunięcia podatności. Sam błąd nie jest specyficzny dla MPTCP, a pozostawienie jednego dostępnego listenera może zachować drogę ataku. Go Security Team zaleca aktualizację kernela i określa wyłączanie MPTCP osobno w aplikacjach jako rozwiązanie zawodne. Komunikat Go Security Team.

Dostępność poprawek: sprawdzaj konkretny pakiet

Status dystrybucji zmienia się niezależnie od publikacji poprawki w głównym projekcie Linux. Poniższe informacje pochodzą z komunikatów dostępnych podczas przygotowania wpisu; przed wdrożeniem sprawdź wskazane źródło ponownie.

  • Ubuntu: karta CVE, zaktualizowana 30 października, oznacza podstawowy pakiet linux dla 22.04 LTS, 24.04 LTS, 26.04 LTS i 26.10 jako podatny, z poprawką w przygotowaniu. Wymieniony planowany numer pakietu nie oznacza, że został on już wydany. Warianty HWE, chmurowe i pozostałe mają osobne wiersze. Status Ubuntu.
  • Red Hat: biuletyn z 30 października wymienia RHEL 8, 9, 10 oraz OpenShift i zapowiada przyspieszenie wydania poprawek. Zawiera również procedurę ograniczenia ekspozycji. Biuletyn RHSB-2026-016.
  • Debian: tracker wskazuje poprawione pakiety źródłowe linux w wersjach 6.1.190-1 dla bookworm i 6.12.113-1 dla trixie oraz linux-6.12 w wersji 6.12.113-1~deb12u1 dla bookworm. Tracker Debiana.
  • Amazon Linux 2023: poprawki dla gałęzi kernel6.18 i kernel6.12 opisują odpowiednio ALAS2023-2026-3251 i ALAS2023-2026-3335. Sprawdź biuletyn odpowiadający gałęzi używanej przez host.

Starsze doniesienia przytaczały niższą ocenę Red Hat. Aktualna karta producenta wskazuje już 9,8. Również numer głównej wersji kernela nie rozstrzyga o bezpieczeństwie: dystrybucje przenoszą poprawki do starszych gałęzi. Porównuj pełną wersję pakietu z biuletynem dostawcy. Ocena i wyjaśnienie backportów Red Hat.

Procedura dla administratora

1. Spisz hosty i działające kernele

Zacznij od serwerów przyjmujących połączenia z internetu. Następnie obejmij przeglądem maszyny wewnętrzne, węzły klastrów, środowiska testowe i obrazy maszyn używane do automatycznego skalowania. Zapisz właściciela każdej usługi i dostępne okno aktualizacji.

Na hoście zbierz podstawowe informacje:

cat /etc/os-release
uname -r
ss -lnt

uname -r pokazuje uruchomione jądro. Lista z ss pomaga zinwentaryzować porty TCP, ale sama nie dowodzi dostępności z internetu ani nie jest testem podatności lub pełnym wykazem MPTCP. Wyniki połącz z konfiguracją firewalla, load balancerów i reguł dostępu w chmurze.

2. Dobierz aktualizację do dystrybucji

Ustal nazwę i pełną wersję pakietu kernela oraz jego wariant, np. standardowy, HWE lub chmurowy. Sprawdź, czy właściwy biuletyn potwierdza naprawę CVE-2026-98432. Zainstaluj poprawkę ze wspieranego repozytorium dostawcy zgodnie z procedurą dla danego środowiska.

Przed restartem zweryfikuj kopię zapasową, dostęp do konsoli i możliwość uruchomienia poprzedniego kernela w razie awarii. Powrót do podatnej wersji wymaga ponownego ograniczenia ekspozycji i dalszego planu naprawy.

3. Potwierdź uruchomienie poprawionego jądra

Po zaplanowanym restarcie ponownie sprawdź uname -r i powiąż wynik z poprawionym pakietem. Samo pobranie aktualizacji nie zmienia już działającego kernela. Jeśli korzystasz z live patchingu, wymagaj potwierdzenia dostawcy, że konkretna aktywna poprawka obejmuje to CVE.

Sprawdź dostępność usług, logowanie użytkowników, połączenia z bazą oraz monitoring. Zapisz wersję, czas wdrożenia i wynik weryfikacji przy każdym hoście.

4. W Kubernetes uwzględnij węzły

Zwykłe kontenery linuksowe współdzielą jądro hosta. Aktualizacja obrazu aplikacji nie aktualizuje kernela węzła. Zaplanuj rotację lub aktualizację węzłów, uwzględniając dostępne repliki, pojemność klastra i PodDisruptionBudget. Popraw również bazowy obraz maszyn, aby autoscaling nie przywracał podatnej wersji.

Co zrobić, gdy poprawka jeszcze nie jest dostępna

Red Hat opublikował procedurę filtrowania przychodzących pakietów IPv4 TCP zawierających opcje IP. Producent zaznacza, że ogranicza ona ekspozycję, lecz nie zapewnia pełnej ochrony i nie zastępuje aktualizacji. Opcje IP nie są tym samym co opcje TCP. Reguły trzeba sprawdzić w kontekście własnej sieci i przetestować przed wdrożeniem. Procedura Red Hat.

Operacyjnie warto ograniczyć zbędny dostęp do usług, przypisać odpowiedzialność za śledzenie komunikatów i wyznaczyć termin ponownej oceny. Nie zamykaj zgłoszenia bezpieczeństwa po samym zastosowaniu obejścia. Warunkiem zamknięcia powinno być potwierdzenie poprawki na działającym systemie.

Jak może pomóc Opselis

W ramach administracji IT pomagamy zinwentaryzować serwery, zaplanować aktualizacje i sprawdzić usługi po restarcie. W ramach security i hardeningu weryfikujemy ekspozycję oraz priorytety napraw. Jeśli potrzebujesz wsparcia przy tej podatności, skontaktuj się z nami, podając dystrybucje, liczbę hostów i wymagania dotyczące dostępności.