Czarny dzień dla Linuksa? Krytyczna luka TCP CVSS 9.8 i exploit zdalnego roota napisany przez Claude

Linux ponownie znalazł się w centrum poważnego incydentu bezpieczeństwa. CVE-2026-98432, krytyczna podatność w obsłudze połączeń IPv4 TCP, może prowadzić do zdalnej eskalacji uprawnień aż do roota. Według Anthropic wewnętrzny, niepubliczny model badawczy Claude wygenerował działający exploit wykorzystujący tę lukę.

Co istotne, problem nie dotyczy wyłącznie egzotycznych modułów czy rzadko używanych usług. Błąd znajduje się w ścieżce obsługi połączeń TCP, z której korzystają serwery przyjmujące połączenia IPv4.

Podatność została ujawniona 15 października 2026 roku, a 24 października otrzymała ocenę CVSS 9.8. W opisywanym stanie na 30 października poprawione jądra były już dostępne dla części dystrybucji, jednak Red Hat i Ubuntu nadal nie udostępniły odpowiednich aktualizacji dla wielu wspieranych wersji.

To drugi poważny problem bezpieczeństwa Linuksa opisywany tego samego dnia. W poprzednim artykule omawialiśmy ZDI-CAN-33367, lokalną eskalację uprawnień powiązaną z Dirty Frag. Tym razem mamy do czynienia z błędem, którego udokumentowana ścieżka ataku zaczyna się z poziomu sieci.

CVE-2026-98432 – najważniejsze informacje

Parametr	Informacja
Identyfikator	CVE-2026-98432
Typ podatności	Use-after-free, race condition
Komponent	Obsługa IPv4 TCP w jądrze Linuksa
Ocena CVSS zespołu kernel CVE	9.8 – Critical
Wektor ataku	Sieciowy
Wymagane uwierzytelnienie	Brak
Wymagane uprawnienia	Brak
Potencjalny skutek	Zdalne wykonanie poleceń z uprawnieniami roota
Początek problemu	Linux 4.4, styczeń 2016
Poprawka upstream	5 października 2026
Publiczne wykorzystanie w atakach	Brak potwierdzonych przypadków w stanie na 30 października 2026

Warto zaznaczyć, że CVSS 9.8 odnosi się do oceny zespołu kernel CVE. Red Hat, Oracle, SUSE i Amazon przyjęły ocenę 8.1, uznając złożoność ataku za wysoką. Rozbieżność wynika przede wszystkim z oceny trudności wygrania wyścigu między wątkami jądra.

Exploit zdalnego roota wygenerowany przez model Claude

27 października Anthropic poinformowało, że wewnętrzny model badawczy Claude, który nie został publicznie udostępniony, opracował działający exploit dla CVE-2026-98432.

Według opisu Anthropic atak pozwala zdalnemu napastnikowi, bez poświadczeń, wykonywać polecenia jako root na serwerze Linuksa posiadającym nasłuchujący socket Multipath TCP (MPTCP).

W demonstracji model miał opracować exploit w dwóch etapach:

1. Wykorzystanie błędu wyścigu do uzyskania wycieku adresu z pamięci jądra, co pozwalało pokonać mechanizm KASLR.
2. Wykorzystanie podatności do nadpisania wskaźnika funkcji zwrotnej i skierowania wykonania kodu na przygotowany payload.

Anthropic podało, że etap uzyskania wycieku adresu zajmował około 48 minut, a uzyskanie wykonania poleceń kolejne pięć minut.

Czy exploit jest publicznie dostępny?

Nie. Według materiału TuxCare na 30 października:

• Anthropic nie opublikowało kodu exploita.
• Nie ujawniono dokładnej wersji jądra ani konfiguracji testowej.
• TuxCare nie odtworzyło niezależnie exploita.
• Nie odnotowano publicznej, niezależnej reprodukcji.
• Nie zgłoszono potwierdzonych przypadków wykorzystania podatności w rzeczywistych atakach.

Nie należy więc przedstawiać sprawy jako potwierdzonej kampanii cyberprzestępczej. Mamy jednak do czynienia z poważnym sygnałem: model AI miał przełożyć opis błędu jądra na działający łańcuch zdalnego przejęcia uprawnień.

Co więcej, zespół kernel CVE już wcześniej opisał możliwość wycieku pamięci i niekontrolowanych zapisów poza granicami bufora. Anthropic miało zbudować exploit wykorzystujący właśnie te właściwości.

Techniczne źródło problemu: use-after-free w obsłudze TCP

CVE-2026-98432 jest błędem typu use-after-free (UAF), występującym w ścieżce obsługi handshake IPv4 TCP.

Use-after-free oznacza sytuację, w której kod nadal korzysta z obszaru pamięci po tym, jak został on zwolniony. W jądrze Linuksa takie błędy mogą prowadzić do:

• odczytu nieaktualnych danych,
• wycieku informacji z pamięci jądra,
• uszkodzenia struktur danych,
• niekontrolowanych zapisów,
• potencjalnego przejęcia przepływu wykonania.

W tym przypadku problem związany jest z obsługą opcji IPv4 TCP podczas ustanawiania połączenia.

Jak dochodzi do wyścigu?

Podatność wykorzystuje pakiet TCP SYN zawierający opcje IPv4, konkretnie Record Route lub Timestamp.

W normalnym ruchu sieciowym opcje te występują rzadko. Nie są jednak zabronione, a klient może wysłać pakiet SYN, który je zawiera.

W uproszczeniu przebieg podatnej operacji wygląda następująco:

1. Serwer otrzymuje pakiet SYN z opcjami IPv4.
2. Jądro zapisuje opcje w strukturze ireq_opt, związanej z oczekującym połączeniem.
3. Po zakończeniu handshake funkcja tcp_v4_syn_recv_sock() przekazuje opcje do nowego socketu potomnego.
4. W podatnej ścieżce obie struktury wskazują na tę samą pamięć, zamiast korzystać z niezależnej kopii.
5. Klient może retransmitować SYN w odpowiednim momencie, uruchamiając równoległą ścieżkę budowania SYNACK.
6. Jeśli socket potomny zostanie w międzyczasie zniszczony, inet_sock_destruct() zwalnia pamięć zawierającą opcje.
7. Ścieżka przygotowująca SYNACK może nadal odczytywać zwolnioną pamięć.

W ten sposób powstaje wyścig pomiędzy zwolnieniem pamięci a jej ponownym wykorzystaniem.

Dlaczego wyścig jest trudny do wykorzystania?

Atakujący musi odpowiednio zsynchronizować retransmisję SYN oraz moment zwalniania socketu.

Nie każda próba zakończy się powodzeniem. Nie oznacza to jednak, że podatność jest niegroźna.

Nieudana próba wykorzystania wyścigu powoduje niepowodzenie pojedynczego handshake, a niekoniecznie awarię całego serwera. Atakujący może więc ponawiać próby, dopóki port pozostaje dostępny.

Właśnie ten aspekt jest istotny z punktu widzenia oceny ryzyka: brak natychmiastowego crasha nie oznacza, że podatność nie może zostać wykorzystana.

Skąd wzięła się podatność? Błąd obecny od 2016 roku

CVE-2026-98432 nie jest błędem wprowadzonym przez najnowszą wersję Linuksa.

Źródło problemu sięga commita:

079096f103fa
tcp/dccp: install syn_recv requests into ehash table

Zmiana ta została wprowadzona w Linux 4.4 w styczniu 2016 roku. Umożliwiła przetwarzanie socketów żądań bez konieczności utrzymywania blokady socketu nasłuchującego.

W konsekwencji podatna ścieżka mogła istnieć w jądrze przez niemal dziesięć lat.

Red Hat wskazuje RHEL 7 jako niewrażliwy na ten problem, podobnie CentOS 7, który korzysta z tej samej linii jądra.

To kolejny przykład tego, jak pozornie niewielka zmiana w mechanizmie współbieżności może po latach ujawnić poważne konsekwencje bezpieczeństwa.

Poprawka upstream: kfree_rcu zamiast kfree

Poprawkę przygotował Eric Dumazet. Jej zakres jest niewielki – obejmuje zmianę dwóch wywołań zwalniających pamięć.

W plikach:

net/ipv4/af_inet.c
net/ipv4/tcp_ipv4.c

wywołania kfree() zostały zastąpione przez kfree_rcu().

Czym różnią się te funkcje?

kfree() zwalnia obszar pamięci bezpośrednio. Jeżeli inna ścieżka kodu nadal korzysta ze wskaźnika do tej pamięci, może dojść do use-after-free.

kfree_rcu() wykorzystuje mechanizm RCU (Read-Copy-Update). Pamięć jest zwalniana dopiero wtedy, gdy zakończą się odpowiednie sekcje odczytu, które mogły korzystać z danego obszaru.

W kontekście CVE-2026-98432 rozwiązanie to pozwala zapewnić, że ścieżka przygotowująca SYNACK nie odczyta opcji TCP po ich przedwczesnym zwolnieniu.

Jest to przykład naprawy problemu współbieżności poprzez zmianę momentu zwolnienia pamięci, bez konieczności przebudowy struktur danych.

Czy podatność wymaga włączonego MPTCP?

To jeden z najważniejszych aspektów całego problemu.

Sama podatność znajduje się w obsłudze IPv4 TCP. Jednak exploit opisany przez Anthropic wykorzystywał nasłuchujący socket MPTCP.

MPTCP (Multipath TCP) jest rozszerzeniem TCP pozwalającym na wykorzystanie kilku ścieżek sieciowych w ramach jednego połączenia.

Dlaczego Go może zwiększać ekspozycję?

Od Go 1.24 programy napisane w Go na Linuksie domyślnie włączają MPTCP dla socketów nasłuchujących, o ile jądro obsługuje tę funkcję.

Oznacza to, że serwer API, reverse proxy lub inna aplikacja napisana w Go może posiadać socket MPTCP, nawet jeśli jej administrator nie konfigurował świadomie takiej funkcji.

W przypadku RHEL 8, 9 i 10 sytuacja jest korzystniejsza: Red Hat dostarcza obsługę MPTCP wyłączoną domyślnie. Dotyczy to również dystrybucji bazujących na tych jądrach.

Na standardowej instalacji systemu EL aplikacja Go próbująca utworzyć socket MPTCP może więc przejść do zwykłego TCP.

Nie należy jednak traktować wyłączonego MPTCP jako pełnej ochrony.

Go Security Team wskazuje, że podstawowy błąd nie jest ograniczony wyłącznie do MPTCP. System bez socketu MPTCP może być podatny na podobne scenariusze ataku, choć nie pokazano publicznie przejęcia roota tą drogą.

W praktyce:

• aktywny socket MPTCP zwiększa ekspozycję na demonstrację Anthropic,
• wyłączenie MPTCP ogranicza udokumentowany scenariusz exploita,
• brak MPTCP nie oznacza, że jądro jest naprawione.

Jak sprawdzić, czy serwer korzysta z MPTCP?

Administrator może wykonać kilka poleceń.

Sprawdzenie globalnego ustawienia

sysctl net.mptcp.enabled

Jeżeli wynik wynosi:

net.mptcp.enabled = 1

aplikacje mogą tworzyć sockety MPTCP.

Wartość 0 oznacza, że funkcja jest wyłączona.

Sprawdzenie socketów nasłuchujących

ss -H -lMn

Każdy wiersz wyświetlony przez to polecenie reprezentuje socket MPTCP w stanie nasłuchiwania.

Jeżeli polecenie nie zwraca wyników, na danym hoście nie wykryto socketów MPTCP nasłuchujących w momencie sprawdzania.

Nie oznacza to jednak, że system jest odporny na CVE-2026-98432.

Sprawdzenie parametru migracji żądań TCP

sysctl net.ipv4.tcp_migrate_req

Domyślna wartość wynosi 0.

Wartość 1 otwiera dodatkową, węższą ścieżkę podatności związaną z migracją socketów. Podobny scenariusz może występować, jeśli do socketu SO_REUSEPORT dołączono program BPF typu BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.

Ta ścieżka nie jest jednak wymagana do wykorzystania głównego problemu.

Jak ograniczyć ryzyko przed instalacją poprawki?

Najważniejszym rozwiązaniem jest instalacja poprawionego jądra. Jeśli producent dystrybucji nie udostępnił jeszcze aktualizacji, można zastosować dodatkowe środki ograniczające ekspozycję.

Poniższe działania nie są zamiennikiem poprawki. Według materiału TuxCare nie zostały również przetestowane z publicznym exploitem Anthropic, ponieważ jego kod nie został udostępniony.

1. Wyłączenie MPTCP

Na systemach, które nie korzystają z MPTCP:

sudo sysctl -w net.mptcp.enabled=0

Aby ustawienie przetrwało restart, można utworzyć plik:

sudo nano /etc/sysctl.d/99-disable-mptcp.conf

i umieścić w nim:

net.mptcp.enabled = 0

Następnie zastosować konfigurację:

sudo sysctl --system

Jeżeli aplikacje mają już otwarte sockety MPTCP, należy zrestartować odpowiednie usługi, aby ponownie uruchomiły się z nową konfiguracją.

Dla aplikacji Go można również ustawić:

GODEBUG=multipathtcp=0

Alternatywnie w głównym module Go można użyć wpisu:

godebug multipathtcp=0

Jest to jednak ograniczenie scenariusza demonstracyjnego, a nie naprawa podatności. Pojedynczy pozostawiony socket MPTCP może nadal stanowić zagrożenie.

2. Ograniczenie pakietów TCP z opcjami IPv4

Główna ścieżka podatności wymaga pakietów SYN zawierających opcje IPv4.

TuxCare opisuje regułę nftables, która odrzuca przychodzące pakiety TCP z opcjami IPv4:

sudo nft add table ip cve_2026_98432
sudo nft add chain ip cve_2026_98432 prerouting \
'{ type filter hook prerouting priority -300; }'
sudo nft add rule ip cve_2026_98432 prerouting \
meta l4proto tcp ip hdrlength != 5 drop

Reguła blokuje pakiety TCP, których nagłówek IPv4 ma długość inną niż standardowe 5 słów 32-bitowych, czyli 20 bajtów.

To podejście nie zależy od tego, czy na serwerze działa MPTCP.

Ważne: reguła nie została zweryfikowana z publicznym exploitem. Może też blokować legalny ruch wykorzystujący opcje TCP/IP. Należy ją najpierw przetestować w środowisku stagingowym.

Aby usunąć regułę:

sudo nft delete table ip cve_2026_98432

Powyższa konfiguracja nie przetrwa restartu, jeśli nie zostanie dodana do trwałej konfiguracji zapory.

Filtrowanie opcji IPv4 na brzegu sieci może zapewnić ochronę wielu serwerom jednocześnie, pod warunkiem że cały ruch do tych hostów przechodzi przez odpowiednie urządzenie.

3. Kontrola migracji socketów

Administrator powinien sprawdzić:

sysctl net.ipv4.tcp_migrate_req

Wartość powinna wynosić 0, jeśli migracja nie jest potrzebna.

Warto również zweryfikować, czy do socketów SO_REUSEPORT nie dołączono programu BPF typu BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.

4. Aktualizacja jądra

Jeśli poprawione jądro jest dostępne, należy traktować aktualizację jako priorytet.

W przypadku systemów, w których nie ma jeszcze poprawki, warto monitorować komunikaty producenta oraz rozważyć rozwiązania umożliwiające zastosowanie poprawki bez restartu.

Nie należy opierać decyzji wyłącznie na numerze wersji zwracanym przez uname -r. Dystrybucje enterprise często backportują poprawki do starszych linii jądra.

Które dystrybucje były podatne 30 października 2026?

Stan przedstawiony w materiale TuxCare na 30 października 2026 roku wyglądał następująco:

Dystrybucja	Status
Linux upstream stable	Poprawka dostępna
RHEL 8, 9 i 10	Podatne, brak poprawionego jądra
AlmaLinux 8, 9 i 10	Podatne
Rocky Linux 8, 9 i 10	Podatne
CloudLinux 8, 9 i 10	Podatne
Oracle Linux RHCK 8, 9 i 10	Podatne
RHEL 7 / CentOS 7	Nie dotyczy
Oracle Linux UEK	Poprawione 16 października
Debian 13	Poprawione
Debian 12	Poprawione
Ubuntu 22.04, 24.04, 26.04 i 26.10	Poprawka w przygotowaniu
Ubuntu 16.04, 18.04 i 20.04	Podatne
Amazon Linux 2023 – kernel6.18 i kernel6.12	Poprawione
Amazon Linux 2 i domyślne jądro Amazon Linux 2023	Poprawka oczekująca
SUSE SLES 16.0, SLE Micro 6.2, openSUSE Leap 16.0	Poprawione
SUSE SLES 15 SP7	Poprawka w przygotowaniu

W przypadku jądra upstream poprawione wersje obejmowały m.in.:

5.10.272
5.15.223
6.1.190
6.6.159
6.12.113
6.18.56
7.2.10
7.3

Wartości te należy traktować jako stan na 30 października 2026 r. W przypadku dystrybucji enterprise decydujące znaczenie mają pakiety i advisories producenta.

KernelCare – poprawki bez restartu

TuxCare poinformowało o udostępnieniu poprawki KernelCare dla Debian 13. Wsparcie dla Debian 12 i Oracle Linux UEK było w przygotowaniu.

Poprawki dla systemów EL 8, 9 i 10 – w tym RHEL, AlmaLinux, CloudLinux, Oracle Linux RHCK i Rocky Linux – były budowane niezależnie od harmonogramu Red Hat.

W przypadku Ubuntu nie podano jeszcze daty udostępnienia poprawki KernelCare.

Status na 30 października 2026:

System	KernelCare
Debian 13	Dostępna
Debian 12	W przygotowaniu
Oracle Linux UEK	W przygotowaniu
EL 8, 9 i 10	W przygotowaniu
Ubuntu	Brak dostępnej poprawki
RHEL 7 / CentOS 7	Nie dotyczy

Na Debianie 13 administrator może pobrać aktualizację:

sudo kcarectl --update

Aby sprawdzić, czy poprawka została zastosowana:

kcarectl --patch-info | grep 'CVE-2026-98432'

Patch bez restartu jest szczególnie przydatny dla serwerów produkcyjnych, na których restart jądra wiąże się z przerwą w dostępności usług.

Jak sprawdzić serwer w mniej niż minutę?

TuxCare wskazuje zestaw poleceń, które pozwalają szybko określić podstawowe parametry ekspozycji:

uname -r
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
ss -H -lMn
nft list table ip cve_2026_98432
kcarectl --patch-info | grep 'CVE-2026-98432'

Interpretacja:

• uname -r – pokazuje aktualnie uruchomione jądro.
• net.mptcp.enabled – informuje, czy aplikacje mogą tworzyć sockety MPTCP.
• net.ipv4.tcp_migrate_req – sprawdza konfigurację migracji żądań.
• ss -H -lMn – wykrywa sockety MPTCP nasłuchujące.
• nft list table – pozwala sprawdzić, czy reguła ograniczająca pakiety z opcjami IPv4 została załadowana.
• kcarectl --patch-info – sprawdza stan poprawki KernelCare.

To podstawowa kontrola, a nie pełny test bezpieczeństwa. Numer jądra nie zawsze ujawnia obecność backportowanej poprawki.

Czy to rzeczywiście „czarny dzień dla Linuksa”?

W kontekście dwóch opisywanych podatności określenie „czarny dzień” jest zrozumiałe.

Pierwszy problem, ZDI-CAN-33367, pokazuje, że lokalny użytkownik może uzyskać uprawnienia roota przez błąd w ochronie page cache. Drugi, CVE-2026-98432, wskazuje na potencjalną możliwość zdalnego przejęcia serwera poprzez wyścig w obsłudze TCP.

Oba problemy pokazują, że bezpieczeństwo jądra zależy nie tylko od pojedynczych funkcji, lecz także od współpracy wielu mechanizmów:

• zarządzania pamięcią,
• współbieżności,
• obsługi socketów,
• ochrony przed wyciekiem adresów,
• poprawnego zwalniania struktur danych,
• konfiguracji usług sieciowych.

W przypadku CVE-2026-98432 szczególnie istotny jest czas. Poprawka upstream została przygotowana 5 października, jeszcze przed publikacją CVE. Debian udostępnił poprawione jądro wkrótce po ujawnieniu podatności. Red Hat i Ubuntu pozostawały jednak bez aktualizacji w opisywanym okresie.

To pokazuje, że w środowiskach enterprise samo istnienie poprawki w głównym drzewie Linuksa nie gwarantuje szybkiego zabezpieczenia wszystkich systemów.

Podsumowanie

CVE-2026-98432 to krytyczna podatność typu use-after-free w obsłudze IPv4 TCP, która według Anthropic została wykorzystana przez wewnętrzny model Claude do opracowania zdalnego exploita umożliwiającego uzyskanie uprawnień roota.

Błąd sięga Linux 4.4 i wynika z wyścigu pomiędzy zwalnianiem pamięci zawierającej opcje TCP a ich ponownym wykorzystaniem podczas przygotowywania SYNACK.

Poprawka upstream opiera się na zastosowaniu kfree_rcu() zamiast bezpośredniego kfree(). Mimo niewielkiego zakresu zmiany, jej znaczenie dla bezpieczeństwa jest bardzo duże.

Administratorzy powinni:

• sprawdzić, czy ich system posiada poprawione jądro,
• wykryć aktywne sockety MPTCP,
• wyłączyć MPTCP tam, gdzie nie jest potrzebny,
• zweryfikować konfigurację migracji socketów,
• rozważyć filtrowanie pakietów TCP z opcjami IPv4 po testach,
• monitorować advisories producentów dystrybucji.

Najważniejszy wniosek: CVE-2026-98432 nie jest potwierdzonym atakiem zero-day, ale publiczny opis potencjalnego exploita zdalnego roota sprawia, że nie należy czekać z zabezpieczeniem systemów na pojawienie się pierwszych incydentów.

W zestawieniu z lokalną podatnością Dirty Frag, ujawnioną tego samego dnia, wydarzenia te stanowią poważne ostrzeżenie dla administratorów serwerów Linux.

Źródła

• TuxCare – materiał techniczny dotyczący CVE-2026-98432, stanu poprawek i metod ograniczania ryzyka, stan na 30 października 2026 r.
• Linux Kernel CVE Team – opis podatności i ocena CVSS.
• Anthropic Frontier Red Team – raport z 27 października 2026 r. dotyczący exploitów opracowanych przez wewnętrzny model badawczy.
• Go Security Team – zalecenia dotyczące Multipath TCP w Go 1.24 i późniejszych wersjach.
• Dokumentacja jądra Linuksa dotycząca MPTCP.
• Advisories bezpieczeństwa Debian, Red Hat, Ubuntu, Oracle, SUSE i Amazon Linux.