CVE-2026-98432: Ubuntu i RHEL wciąż nie mają poprawki, a model Claude już napisał exploit

Dwa fakty dotyczące CVE-2026-98432 nie bardzo do siebie pasują. To use-after-free w mechanizmie uzgadniania TCP IPv4 w jądrze Linux, osiągalny przez sieć bez logowania i bez interakcji, a zespół CVE jądra ocenił go na 9,8. Na dzień 30 października 2026 r. Ubuntu nie ma wydanej poprawki dla 22.04, 24.04, 26.04 ani 26.10, a Red Hat wymienia RHEL 8, 9 i 10 jako podatne — bez poprawki i bez oficjalnie popieranego środka łagodzącego. Drugi fakt jest taki, że 27 października Anthropic opublikował badania, według których niewydany model Claude stworzył działający proof of concept dla nieuwierzytelnionego zdalnego uzyskania uprawnień roota na serwerze z nasłuchem MPTCP — około 48 minut na wyciek adresu jądra i jeszcze pięć minut na wykonanie polecenia.

Luka w zabezpieczeniach, której dwóch największych dostawców korporacyjnego Linuksa nie jest jeszcze w stanie załatać, wraz z działającym exploitem napisanym częściowo przez maszynę, to nie jest rutynowy patch Tuesday. To sprawa, która rozstrzyga, czy twój proces aktualizacji jądra i twoja polityka dostępu agentów mają ze sobą cokolwiek wspólnego.

Błąd, w jednym akapicie

Gdy nawiązywane jest połączenie TCP, opcje IP dołączone do przychodzącego pakietu są przekazywane nowemu gniazdu, a nie kopiowane. Jeśli handshake zostanie przesłany ponownie, pakiet może zostać przetworzony na innym CPU niż ten, który jest właścicielem bufora opcji — a ten drugi CPU może odczytać pamięć, którą pierwszy już zwolnił. Podobny wyścig występuje na ścieżce migracji żądań. Zakres objętych wersji zaczyna się od jądra 4.4, co oznacza, że dotyczy to większości maszyn nadal działających na utrzymywanym jądrze. Poprawka upstream, commit code>e3f33b0a1d89/code>, opóźnia zwolnienie buforów opcji do czasu, gdy żaden inny rdzeń nie może już trzymać referencji.

Możliwość wykorzystania wynika z mechaniki: brak uwierzytelniania, brak interakcji użytkownika, ścieżka osiągalna przez sieć oraz wyścig, który można ponawiać. Anthropic w swoim własnym podsumowaniu wyjaśniającym, dlaczego PoC jest praktyczny, wskazuje dokładnie tę właściwość — przegrany wyścig powoduje niepowodzenie pojedynczego handshake'u zamiast awarii maszyny, więc atakujący próbuje ponownie.

Trzech dostawców, trzy liczby określające stopień dotkliwości

Podział punktacji to część warta przyswojenia, ponieważ decyduje, czy Twój skaner otworzy zgłoszenie w tym tygodniu.

• Zespół CVE jądra — 9.8, krytyczny. Osiągalny z sieci, nie wymaga uprawnień ani interakcji.

• Red Hat — 8.1, Ważne. Stanowisko firmy jest takie, że w praktyce trudno wygrać ten wyścig.

• Ubuntu — Wysoki priorytet, bez opublikowanej punktacji liczbowej na sprawdzonych stronach.

Różnica między 9.8 a 8.1 nie dotyczy sporu o sam błąd; dotyczy sporu o prawdopodobieństwo wygrania wyścigu. Obie oceny da się bronić, a różnica ma znaczenie operacyjne: 9.8 z publicznym PoC to sytuacja awaryjna, 8.1 z trudnym wyścigiem to zaplanowana poprawka. Dopóki ktoś nie opublikuje wyników reprodukcji na rzeczywistym sprzęcie, uczciwa interpretacja jest taka, że wyścig da się wygrać, ponieważ model frontier podobno go wygrał.

Kto ma poprawkę, a kto nie

Na dzień 29–30 października obraz jest niejednolity w sposób, który zaskakuje osoby zakładające, że stabilne jądro oznacza załatane.

• Debian 12 bookworm — poprawiono w 6.1.190-1 poprzez DLA-4841-1.

• Debian 13 trixie — naprawione w 6.12.113-1 poprzez DSA-6568-1.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — brak wydanej poprawki; prace w toku.

• Ubuntu 16.04, 18.04, 20.04 — podatne, brak wydanej poprawki.

• RHEL 8, 9, 10 i OpenShift 4 — dotyczy, brak poprawki i brak środków zaradczych zatwierdzonych przez Red Hat.

• RHEL 6 i 7 — nie dotyczy.

• Amazon Linux 2023 — jądro 6.18 zgłoszone jako naprawione; Oracle Linux UEK zgłoszone jako naprawione; SUSE podaje, że niektóre wydania są naprawione, a inne wciąż w fazie testów, bez podawania numerów wersji.

Wydania stabilne upstream zawierające tę poprawkę to 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 i 7.3 — to lista, z którą należy porównać własną kompilację, jeśli kompilujesz jądro samodzielnie, zamiast korzystać z pakietu dystrybucji.

Dlaczego MPTCP wciąż się pojawia

Błąd nie jest specyficzny dla MPTCP i właśnie tutaj wiele relacji jest błędnych. Red Hat traktuje każdą osiągalną usługę TCP jako możliwy czynnik wyzwalający. To, co zapewnia MPTCP, to zademonstrowana ścieżka, a ruch zapewnia Go: wersja 1.24 i późniejsze domyślnie włącza wielościeżkowe TCP dla gniazd nasłuchujących w Linuksie, gdy w jądrze włączono MPTCP. Zespół bezpieczeństwa Go ostrzegł o tym połączeniu 29 października.

Zatem „disable MPTCP” usuwa ścieżkę, którą zademonstrował Anthropic, a nie samą podatność. To możliwy do obrony środek tymczasowy z konkretnym zastrzeżeniem: warto go wdrożyć dziś w usługach Go, ale nie zastępuje on jądra z poprawką.

Kontrole są krótkie:

• code>ss -Mltnp/code> — wyświetl gniazda aktualnie używające MPTCP.

• code>net.mptcp.enabled/code> — czy funkcja jądra jest w ogóle włączona.

• code>net.ipv4.tcp_migrate_req/code> — domyślnie wyłączona; jeśli została włączona, wyłącz ją ponownie.

W szczególności w przypadku Go, code>GODEBUG=multipathtcp=0/code> w czasie działania lub wiersz code>godebug/code> w code>go.mod/code> powoduje, że plik binarny rezygnuje z tej opcji.

Żadne z nich nie zostało zatwierdzone przez dostawcę. Red Hat jasno stwierdza, że nie ma środka łagodzącego spełniającego jego własny standard, co jest bardziej użytecznym zdaniem niż lista obejść opartych na nadziei.

Co Anthropic faktycznie opublikował?

Badanie jest wąskie i konkretne. Nieopublikowany model Claude, otrzymawszy CVE oraz cel z uruchomionym nasłuchem MPTCP, wytworzył łańcuch, który ujawnił adres jądra w ciągu około 48 minut, a mniej więcej pięć minut później doprowadził do wykonania poleceń. Anthropic nie opublikował tego exploita, a według stanu na 29 października ani dostawcy, ani wpis CVE nie zgłosiły ataków w środowisku naturalnym; podatność nie znajduje się w katalogu KEV CISA. 30 października repozytorium GitHub podmiotu trzeciego opublikowało narzędzia laboratoryjne do wyzwalania wyścigu i wycieku pamięci — stanowisko do reprodukcji, nieobejmujące pełnego wykonania kodu.

To połączenie jest interesującym elementem. Zdolność została zademonstrowana, broń pozostaje wstrzymana, a szczegół umożliwiający — właściwość ponawiania, która zamienia kruchy wyścig w niezawodny — jest publicznie dostępny w formie prozy. Każdy, kto potrafi odtworzyć ten wyścig, wie już, dlaczego warto przy nim wytrwać.

Co robić w tym tygodniu

• Zastosuj poprawkę i uruchom ponownie system, jeśli poprawka jest dostępna. Poprawka jądra, która została zainstalowana, ale system nie został ponownie uruchomiony, nie jest poprawką; zweryfikuj za pomocą code>uname -r/code>.

• Tam, gdzie Twoja dystrybucja nie ma poprawki — Ubuntu od 22.04 do 26.10, RHEL od 8 do 10 — zdecyduj teraz, czy skorzystasz z poprawki na żywo (live patch) od dostawcy, czy przejdziesz na wersję z poprawką, czy zaakceptujesz ekspozycję przy wyłączonym MPTCP w usługach Go.

• Zinwentaryzuj ekspozycję MPTCP, zamiast zakładać, że jest wyłączony. Domyślne ustawienie zmieniło się w Go, a nie w Twojej konfiguracji, a zmiana wartości domyślnej jest niewidoczna w diffie konfiguracji.

• Przećwicz restart. Ten rodzaj poprawki wymaga pełnego restartu, a najbardziej stracą te organizacje, które swój plan przełączania awaryjnego odkrywają dopiero podczas okna konserwacyjnego.

Dwa pytania, które ten CVE faktycznie stawia

Pierwszy dotyczy generowania exploitów i nie ma charakteru filozoficznego. Model znalazł sekwencję, której bardzo wielu ludzkich badaczy nie znalazło, na celu o określonej konfiguracji umożliwiającej, w ciągu niecałej godziny. Niezależnie od tego, czy exploit zostanie opublikowany, oś czasu się zmieniła: okno między publicznym komunikatem doradczym a działającym exploitem jest teraz mierzone względem modeli, które czytają ten komunikat.

Druga kwestia dotyczy tego, co oznacza łatanie, gdy dostawcy nie mogą wprowadzać poprawek. Dystrybucja, która dostarcza ci jądro, i jądro, które zawiera poprawkę, to nie ten sam obiekt, a luka między nimi jest dokładnie tym miejscem, w którym ta podatność występuje dla większości czytelników tego wpisu. OrcaRouter AI Incident Archive indeksuje tego typu incydenty w odniesieniu do ich źródeł pierwotnych, dotkliwości i poziomu pewności, co stanowi wersję tej historii wartą zachowania, gdy cykl informacyjny się zmieni.

Nie należy tego wrzucać do szufladki „poczekamy na dostawcę”. Strona samego dostawcy mówi, że na razie nie ma na co czekać.

Uwaga dotycząca źródeł: mechanizm, zakres objętych wersji od jądra 4.4, commit upstream code>e3f33b0a1d89/code, lista wersji stabilnych oraz wytyczne dotyczące łagodzenia pochodzą z rekordu CVE i porad dystrybucyjnych czytanych 30 października 2026. Oceny 9.8, 8.1 i High Ubuntu to odpowiednio oceny zespołu CVE jądra, Red Hat i Canonical. Status poprawek dla poszczególnych dystrybucji pochodzi z Debian DLA-4841-1 i DSA-6568-1, ze stron CVE Red Hat i Ubuntu oraz z oświadczeń dostawców z tego samego dnia. Kalendarium proof-of-concept, liczby 48 minut i pięciu minut oraz właściwość ponawiania pochodzą z badań Anthropic z 27 października, które wstrzymały publikację exploita. Repozytorium laboratoryjne z 30 października jest określane jako zewnętrzne i nie jest nasze.