CVE-2026-98432: Krytyczna luka w module TCP jądra Linux umożliwia zdalne wykonanie kodu

Krytyczna luka w jądrze Linuxa w stosie sieciowym TCP IPv4 może pozwolić zdalnemu atakującemu, bez uwierzytelnienia, na wywołanie uszkodzenia pamięci, spowodowanie awarii systemów z luką oraz potencjalnie na wykonanie dowolnego kodu z uprawnieniami roota. Błąd śledzony jako CVE-2026-98432 posiada ocenę CVSS 3.1 na poziomie 9.8 i istnieje w jądrze Linuxa od wersji 4.4.

Luka wynika z problemu z warunkami wyścigu, które mogą spowodować, że jądro uzyska dostęp do danych opcji IP po tym, jak podstawowa pamięć została już zwolniona. Atakujący, który ma dostęp do widocznej usługi TCP IPv4, może spróbować wywołać ten warunek, używając specjalnie wyczilowanych żądań połączeń zawierających opcje IPv4. Nie jest wymagana żadna autoryzacja, lokalne uprawnienia ani interakcja użytkownika.

Zainteresowanie bezpieczeństwem znacząco wzrosło po ujawnieniu przez Anthropic, że wewnętrzny model badawczy Claude opracował działający exploit zdolny do uzyskania zdalnego wykonania poleceń z uprawnieniami roota na serwerze Linux działającym z nasłuchującym Multipath TCP (MPTCP). Exploit najpierw wycieka wskaźnik jądra, aby obejść KASLR, a następnie wykorzystuje ten sam warunek use-after-free, aby uszkodzić pamięć i przekierować przepływ sterowania jądra. Anthropic nie opublikował kodu exploita.

Co ważne, podstawowa luka nie jest ograniczona do MPTCP. Red Hat potwierdza, że systemy ze zwykłym sieciowaniem TCP IPv4 pozostają narażone nawet wtedy, gdy MPTCP jest wyłączone, w tym domyślne konfiguracje Red Hat Enterprise Linux.

Skontaktuj się z działem sprzedaży

Na dzień 4 listopada 2026 r. żaden dostawca Linuxa, CERT ani inne sprawdzone źródło nie zgłosiło potwierdzonych wykorzystywań tej luki w rzeczywistych atakach. Istnieje publiczny kod badawczy demonstrujący części luki, ale nie udokumentowano publicznie wydanego exploita zapewniającego pełne zdalne uprawnienia root, jak pokazało Anthropic.

Zespoły ds. bezpieczeństwa mogą korzystać z AI-Native Detection Intelligence Platform SOC Prime, aby wzmocnić swoją obronę przed wykorzystywaniem nowych luk, wdrażać inteligencję zagrożeń i przyspieszać polowanie na zagrożenia w środowiskach SIEM, EDR, XDR i Data Lake.

Wykrywaj CVE-2026-98432 monitorując nietypowy ruch TCP IPv4 zawierający opcje IP, powtarzające się próby połączeń zaprojektowane do wywołania warunków wyścigu, awarie jądra lub zdarzenia uszkodzenia pamięci oraz podejrzaną aktywność, która mogłaby wskazywać na udaną eksploatację po wykonaniu.

Treści dotyczące wykrywania mogą nie być dostępne dla każdego CVE. Sprawdź platformę SOC Prime pod kątem bieżącej ochrony. Jeśli odpowiednie wykrycia nie są jeszcze dostępne, sprawdź ponownie, ponieważ nowe informacje o zagrożeniach i treści dotyczące wykrywania są stale dodawane.

analiza CVE-2026-98432

CVE-2026-98432 wpływa na kod obsługi połączeń TCP IPv4 w jądrach Linuxa zawierających podatną implementację wprowadzoną w Linuxie 4.4. Zespół zajmujący się CVE jądra Linuxa klasyfikuje ten problem jako krytyczny z oceną CVSS 3.1 na poziomie 9.8 oraz wektorem AV/AC/PR/UI/S/C/I/A.

Luka to warunek use-after-free spowodowany wyścigiem podczas współbieżnego przetwarzania połączeń TCP. Gdy zostanie ustanowione połączenie TCP IPv4, tcp_v4_syn_recv_sock() przenosi opcje IP związane z oczekującym żądaniem do nowo utworzonego gniazda bez tworzenia osobnej kopii.

Inny CPU może jednocześnie przetwarzać retransmitowane SYN związane z tym samym gniazdem żądania. Podczas tego procesu funkcje odpowiedzialne za generowanie SYN-ACK nadal odczytują opcje IP chronione krytyczną sekcją odczytu po stronie RCU.

Jednakże gniazdo potomne może zostać zniszczone, zanim ta operacja się zakończy. Jądro wtedy zwalnia powiązaną strukturę inet_opt za pomocą kfree(), pozostawiając inny procesor mogący potencjalnie uzyskać dostęp do pamięci, która została już uwolniona. Powstałe w ten sposób nieaktualne odniesienie tworzy warunek use-after-free w ip_options_build().

Podobny wyścig istnieje podczas migracji gniazda żądania, w tym konfiguracji korzystających z net.ipv4.tcp_migrate_req=1 lub BPF SK_REUSEPORT_SELECT_OR_MIGRATE. Naprawa z górnego drzewa zastępuje niebezpieczne zwolnienie pamięci zwolnieniem świadomym RCU, zapewniając, że czytelnicy zakończyli dostęp do obiektu przed zwrotem jego pamięci.

Pierwszy problem dotyczy konkretnie IPv4. Doradztwo jądra wskazuje, że IPv6 nie jest podatne na ten wyścig, ponieważ tcp_v6_syn_recv_sock() duplikuje odpowiednie opcje zamiast przenosić je w ten sam sposób.

Zdalne wykorzystanie wymaga specjalnie skonstruowanego ruchu sieciowego i precyzyjnej manipulacji warunkiem wyścigu. Red Hat zauważa, że prawdopodobne wyniki to m.in. awaria jądra, uszkodzenie pamięci i potencjalnie zdalne wykonanie kodu. Brak uwierzytelnienia i interakcji użytkownika znacząco zwiększa ryzyko dla systemów udostępniających usługi TCP niezaufanym sieciom.

Anthropic wykazał, że luka może być przekształcona w pełny zdalny exploit z uprawnieniami root. Jej model badawczy celował w serwer Linux akceptujący połączenia Multipath TCP i użył dwóch etapów, aby osiągnąć wykonanie poleceń.

Podczas pierwszego etapu exploit wielokrotnie wyzwala wyścig i manipuluje wartością długości, tak aby jądro zwracało dodatkową sąsiednią pamięć w odpowiedzi sieciowej. W końcu jedna z tych odpowiedzi zawiera wskaźnik jądra. To ujawnienie dostarcza informacji o układzie pamięci jądra i pozwala exploitowi ominąć losowe rozmieszczenie przestrzeni adresowej jądra (KASLR).

Podczas drugiego etapu exploit wykorzystuje tę samą lukę, aby spowodować przepełnienie bufora i nadpisać wskaźnik zwrotny. Wskaźnik jest przekierowany na ładunek wcześniej umieszczony w pamięci jądra za pomocą legalnej funkcjonalności protokołu. Gdy jądro wywołuje zmodyfikowany wskaźnik zwrotny, istniejące funkcje jądra są łańcuchowo połączone, aż atakujący wybierze polecenie powłoki do wykonania z uprawnieniami root.

Szczególnie ważną cechą exploita jest to, że przegranie wyścigu niekoniecznie powoduje awarię serwera. Zamiast tego próba połączenia może się po prostu nie udać, pozwalając atakującemu na wielokrotne ponowienie próby. W środowisku testowym Anthropica uzyskanie przydatnego wskaźnika jądra zajęło około 48 minut, a kolejne pięć minut, aby osiągnąć wykonanie polecenia z uprawnieniami root.

Tego pokazania nie należy interpretować jako koniecznego wykorzystania MPTCP do eksploatacji. Anthropic zaprezentował udaną ścieżkę exploita obejmującą nasłuchiwacza MPTCP, ale podatny kod znajduje się w zwykłej obsłudze TCP IPv4. Red Hat wyraźnie ostrzega, że wyłączenie MPTCP nie rozwiązuje w pełni problemu i że domyślne instalacje RHEL pozostają podatne, mimo że MPTCP jest domyślnie wyłączone.

Sytuacja z PoC CVE-2026-98432 również ważne jest rozróżnienie od istnienia kompletnego wykorzystanego exploita. Anthropic opracował funkcjonujący dowód koncepcyjny zdalny z uprawnieniami root wewnętrznie, ale nie opublikował go. Publiczny kod zgłaszany przez badaczy bezpieczeństwa może demonstrować lub wykrywać aspekty podstawowego wyścigu i ujawniania pamięci, ale źródła nie dokumentują publicznie wydanego kodu odtwarzającego pełny łańcuch wykonania zdalnego kodu Anthropica.

Lukę zgłosił badacz Anthropica, Xinyang Ge. Poprawka w górnym drzewie jądra Linux została zastosowana 5 października 2026 r., a rekord CVE jądra Linux został opublikowany 15 października. Anthropic publicznie opisał swoje pełne badania nad eksploatacją 27 października.

Projekt jądra Linux identyfikuje następujące naprawione wersje w górnym drzewie:

• Linux 5.10.272
• Linux 5.15.223
• Linux 6.1.190
• Linux 6.6.159
• Linux 6.12.113
• Linux 6.18.56
• Linux 7.2.10
• Linux 7.3

Zespół jądra zaleca aktualizację do najnowszego stabilnego jądra zamiast wybierania pojedynczych commitów.

Ekspozycja i remediacja uzależniona od dystrybucji różnią się, ponieważ dostawcy Linuxa utrzymują własne jądra i wprowadzają poprawki bezpieczeństwa. Red Hat aktualnie ocenia problem jako krytyczny z oceną 9.8 i wydał poprawki dla wielu wersji RHEL 8, 9 i 10. OpenShift i produkty warstwowe zależne od zainstalowanych jader RHEL również wymagają uwagi.

Ubuntu również ocenia lukę jako krytyczną z oceną 9.8. Ubuntu 26.10 otrzymało poprawione jądro ogólne, a poprawki dla Ubuntu 22.04 LTS, 24.04 LTS i 26.04 LTS były dostępne w -proposed pocket do testowania na początku listopada, z dodatkowymi wersjami oczekującymi na poprawki. Administratorzy powinni korzystać z strony CVE Canonicala, a nie polegać wyłącznie na numerach wersji jądra górnego drzewa.

Do wykrywania CVE-2026-98432 zespoły ds. bezpieczeństwa powinny łączyć telemetrię sieciową i hostową. Potencjalne sygnały poszukiwania na poziomie sieci obejmują nietypowe pakiety TCP IPv4 przychodzące z zawartymi opcjami IP, szczególnie powtarzające się próby połączeń zawierające opcje Record Route lub Timestamp oraz nietypowe wzorce powtórnej transmisji SYN. Obecność takiego ruchu samodzielnie nie potwierdza eksploatacji, ale stanowi użyteczny punkt wyjścia do poszukiwań przy korelacji z systemami podatnymi na atak.

Monitorowanie na poziomie hosta powinno obejmować awarie jądra Linuxa, ostrzeżenia jądra, wskaźniki uszkodzenia pamięci, nieoczekiwane ponowne uruchomienia usług oraz anomalię w zachowaniu zaraz po podejrzanym ruchu sieciowym. Ponieważ pomyślne wykorzystanie luki może teoretycznie zapewnić wykonanie kodu z uprawnieniami root, obrońcy powinni również monitorować nieoczekiwane procesy uprzywilejowane, nowo utworzone pliki, zmiany w konfiguracji, mechanizmy trwałości oraz niewyjaśnione połączenia wychodzące.

Obecnie nie ma specyficznych dla atakujących IOC dla CVE-2026-98432, takich jak potwierdzone złośliwe adresy IP, domeny lub hashe malware, ponieważ recenzowane źródła nie zgłosiły rzeczywistych ataków w realnym świecie. Obrońcy powinni zatem priorytetowo traktować wykrywanie oparte na zachowaniu i ocenę narażenia zamiast polegać na statycznych wskaźnikach.

Zabezpieczenie CVE-2026-98432

Definitywna remediacja to zainstalowanie dostarczonego przez dostawcę jądra zawierającego poprawkę bezpieczeństwa. Zespół CVE jądra Linux zaleca przejście do najnowszego wspierającego stabilnego jądra, podczas gdy użytkownicy dystrybucji Linux powinni zainstalować pakiety dostarczone specjalnie przez swojego dostawcę, ponieważ poprawki są często wprowadzane bez zmiany numeru wersji jądra górnego drzewa.

Administratorzy powinni priorytetowo traktować serwery Linux wystawione na Internet i inne systemy akceptujące przychodzące połączenia TCP IPv4. Powierzchnia ataku jest szeroka, ponieważ luka istnieje w stosie sieciowym jądra, a nie w pojedynczej aplikacji czy produkcie serwerowym.

Organizacje powinny podjąć następujące kroki:

1. Sporządź inwentaryzację serwerów Linux i zidentyfikuj działające jądra za pomocą narzędzi takich jak uname -r.
2. Sprawdź odpowiednie doradztwo ds. bezpieczeństwa dystrybucji Linux, zamiast określać narażenie wyłącznie na podstawie numeru wersji jądra górnego drzewa.
3. Zainstaluj naprawione jądro dostarczone przez dostawcę, gdy tylko stanie się dostępne.
4. Zrestartuj systemy dotknięte po zainstalowaniu zaktualizowanego jądra, aby upewnić się, że uruchomione jest naprawione jądro.
5. Priorytetyzuj serwery wystawione na Internet i infrastrukturę akceptującą przychodzący ruch TCP IPv4.
6. Przeglądaj zewnętrznie eksponowane usługi TCP i ograniczaj niepotrzebną dostępność sieciową.
7. Kontynuuj monitorowanie doradztw dostawców, ponieważ dostępność poprawek różni się w zależności od dystrybucji Linux, wariantów jądra, jader w chmurach i kanałów wsparcia.

Red Hat i Ubuntu opracowały również tymczasowe podejście do filtrowania pakietów, które odrzuca przychodzące pakiety TCP IPv4 zawierające opcje IP. Rekomendowane warunki nftables sprawdzają, czy długość nagłówka IPv4 jest większa niż pięć i odrzucają pasujące pakiety TCP zanim dotrą do ścieżki przetwarzania gniazda podatnej na wpływy.

To działanie może zmniejszyć narażenie, ponieważ znana ścieżka eksploatacji wymaga opcji IPv4. Jednakże obaj dostawcy ostrzegają, że filtrowanie pakietów nie jest pełnym zamiennikiem dla instalacji poprawionego jądra. Może także zakłócać obciążenia, które legalnie zależą od opcji IPv4, dlatego powinno być przetestowane przed wdrożeniem produkcyjnym.

Wyłączenie samego MPTCP nie powinno być traktowane jako wystarczająca ochrona. Chociaż działający exploit Anthropica wycelował w nasłuchiwacza MPTCP, podstawowa luka znajduje się w normalnym przetwarzaniu TCP IPv4. Red Hat zaznacza, że RHEL pozostaje podatny w swojej domyślnej konfiguracji, mimo że MPTCP jest wyłączone.

Dla środowisk wykorzystujących aplikacje Go, wyłączenie automatycznego zachowania MPTCP może zmniejszyć narażenie na konkretny exploit pokazany przez Anthropica, ale nadal jest to niekompletne działanie redukcji ryzyka. Systemy bez nasłuchiwacza MPTCP nie powinny być automatycznie uważane za bezpieczne, ponieważ inne techniki eksploatacji mogą celować w ten sam podstawowy wyścig.

Ponieważ nie potwierdzono żadnej kampanii kompromitacji w rzeczywistym świecie, obecnie zalecenia dotyczące reakcji na incydenty powinny się skupić na identyfikacji potencjalnie podatnych systemów i podejrzanych zachowań eksploatacyjnych, a nie na wyszukiwaniu znanej infrastruktury atakującego. Organizacje, które zaobserwują nietypowy ruch TCP po którym następuje niestabilność jądra lub nieoczekiwane wykonanie z uprawnieniami powinny traktować takie działania jako potencjalnie złośliwe i zachować telemetrię sieciową oraz hostową do dalszego zbadania.