CVE-2026-98432 — krytyczna luka w jądrze Linuksa (TCP, CVSS 9,8): kogo dotyczy i jak załatać

PawełInstruktor Cyberium Opublikowano 16 października 2026 Zaktualizowano 3 listopada 2026 13 min czytania Poziom: Średni

Co to jest CVE-2026-98432?

CVE-2026-98432 to błąd typu use-after-free (użycie pamięci po jej zwolnieniu) w kodzie jądra Linuksa, który obsługuje nawiązywanie połączeń TCP przez IPv4. Rekord opublikował 15 października 2026 roku zespół CVE jądra Linuksa (kernel.org), a poprawka nosi tytuł „ipv4: free inet_opt and ireq_opt after an RCU grace period” (ogłoszenie kernel CVE team).

Jeśli nie znasz jeszcze skrótów CVE i CVSS, zajrzyj najpierw do naszego przewodnika CVE i CVSS — co to jest i jak czytać wpis o podatności. Tutaj wystarczy prosta wersja.

Jak działa ta podatność — prostym językiem

Połączenie TCP zaczyna się od „uścisku dłoni”: klient wysyła pakiet SYN, serwer odpowiada SYN-ACK. Pakiet SYN może nieść dodatkowe opcje nagłówka IPv4 (np. Record Route albo Timestamp), które jądro zapamiętuje i odsyła w odpowiedzi. Według opisu AlmaLinux z 30 października 2026 roku problem wygląda tak:

1. Gdy połączenie się nawiązuje, kopia opcji przechodzi do nowego gniazda (socketu) — bez duplikowania.
2. Jeśli klient wyśle ten sam SYN ponownie, inny rdzeń procesora może w tym samym momencie budować z tych opcji kolejną odpowiedź SYN-ACK.
3. W międzyczasie połączenie może zostać zamknięte, a jądro od razu zwalnia pamięć z opcjami. Kod budujący SYN-ACK czyta wtedy pamięć, która już do niczego nie należy.

To klasyczny wyścig (race condition). Poprawka Erica Dumazeta opóźnia zwolnienie pamięci, aż żaden rdzeń nie może jej czytać (mechanizm RCU).

Dlaczego to zdalna podatność, a nie lokalna?

To podatność zdalna: atakujący nie potrzebuje konta w systemie, wystarczy, że może wysłać pakiety do nasłuchującego portu TCP. Błąd zachodzi w jądrze jeszcze w trakcie uścisku dłoni, zanim aplikacja (serwer WWW, SSH, baza danych) w ogóle zobaczy połączenie. Dlatego nie chroni przed nim ani hasło, ani konfiguracja samej usługi.

Dwie ważne granice:

• IPv6 nie jest dotknięte głównym problemem — jądro kopiuje tam opcje zamiast je przekazywać (rekord CVE).
• Drugi wariant błędu dotyczy migracji gniazd (net.ipv4.tcp_migrate_req lub program BPF), która jest domyślnie wyłączona.

Jak groźna jest CVE-2026-98432? CVSS i wektor

CVE-2026-98432 ma ocenę CVSS 3.1 równą 9,8 na 10 (Critical) z wektorem CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Tę ocenę nadał zespół CVE jądra Linuksa, a Red Hat i Ubuntu przyjęły ten sam wynik i oznaczyły podatność jako krytyczną. NVD na 3 listopada 2026 roku nie dodał własnej oceny (status „Received”) i pokazuje wynik zespołu jądra. Red Hat klasyfikuje błąd jako CWE-825 (Expired Pointer Dereference — użycie wskaźnika do pamięci, która już wygasła); zespół jądra nie podaje CWE. Czym są CWE i jak czytać wpis CVE, wyjaśniamy w przewodniku po CVE i CVSS.

Ubuntu i SUSE podają też CVSS 4.0 = 9,2 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N). Wyników CVSS 3.1 i 4.0 nie porównuje się wprost, bo to różne skale. W wektorze 4.0 zaznaczono AT:P (atak zależy od warunków w systemie ofiary, np. wygrania wyścigu); bez niego wynik wynosiłby 9,3. Zespół jądra ocenia to inaczej: obie strony wyścigu wywołuje atakujący, stąd AC:L. SUSE w CVSS 3.1 dał AC:H i 8,1, a Red Hat zaznacza, że niezawodne zdalne wykonanie kodu wymaga precyzyjnej kontroli sterty.

Ocena 9,8 a prawdopodobieństwo ataku (EPSS)

CVSS mówi, jak poważne są skutki, a EPSS — jak prawdopodobne jest wykorzystanie podatności w ciągu 30 dni. Według FIRST wynik EPSS dla CVE-2026-98432 z 2 listopada 2026 roku to 0,46% (percentyl ok. 40). EPSS rośnie, gdy pojawiają się działające exploity, a przy zdalnej luce w jądrze z opisanym exploitem decyzja jest prosta — aktualizujesz.

Czy jest publiczny exploit i czy CVE-2026-98432 jest w KEV?

Działający exploit istnieje i został publicznie opisany, ale jego kod nie został opublikowany przez autorów; CVE-2026-98432 nie jest w katalogu CISA KEV (stan na 3.11.2026). Szczegóły:

• Anthropic, 27 października 2026 roku: w raporcie o wyszukiwaniu podatności z pomocą modelu Claude firma opisała exploit, który na serwerach Linux z nasłuchującym gniazdem MPTCP (multipath TCP — rozszerzenie TCP pozwalające używać kilku ścieżek sieciowych naraz) wykonuje polecenia jako root, bez poświadczeń i bez udziału użytkownika. W teście wyciek wskaźnika jądra (obejście zabezpieczenia KASLR) trwał 48 minut, a dojście do wykonania polecenia kolejne ok. 5 minut. Raport opisuje technikę ogólnie, bez kodu. Ubuntu (2.11.2026): nie jest znany żaden inny exploit.
• GitHub: repozytoria podające się za PoC (proof of concept — kod demonstrujący podatność) nie zostały niezależnie potwierdzone — nie linkujemy ich i nie uruchamiaj niesprawdzonego kodu.
• CISA KEV: w katalogu Known Exploited Vulnerabilities w wersji z 30 października 2026 roku nie ma CVE-2026-98432.
• AWS, 30 października 2026 roku: w biuletynie 2026-160-AWS firma napisała, że nie ma dowodów na wykorzystanie podatności w atakach.

Ważny niuans z komunikatu zespołu bezpieczeństwa języka Go (29 października 2026): od Go 1.24 programy w Go na Linuksie domyślnie włączają MPTCP dla gniazd nasłuchujących, więc usługa w Go może mieć gniazdo MPTCP bez świadomej konfiguracji. Zespół Go podkreśla jednak, że błąd nie dotyczy wyłącznie MPTCP — najlepsza ochrona to poprawione jądro.

Których wersji jądra i dystrybucji dotyczy CVE-2026-98432?

Podatne są jądra Linuksa od wersji 4.4 bez poprawki; jądra starsze niż 4.4 są poza zakresem błędu. W jądrze z kernel.org poprawka trafiła do wszystkich utrzymywanych gałęzi w dniach 11–19 października 2026 roku (daty wg cdn.kernel.org; 7.3 — tag v7.3 z 19.10.2026, 01:14 czasu polskiego, w UTC jeszcze 18.10):

Gałąź 7.2 nie dostaje już poprawek (EOL od 1.11.2026) — przejdź na 7.3.x. Najnowsze wersje z 30 października 2026 roku to według kernel.org: 7.3.1, 6.18.60, 6.12.115, 6.6.161, 6.1.191, 5.15.224 i 5.10.273 — każda z nich zawiera poprawkę.

Uwaga na numery w dystrybucjach: Red Hat, Debian czy Ubuntu przenoszą poprawki do własnych wersji jądra (tzw. backport). RHEL 9 ma jądro z rodziny 5.14, a mimo to wersja 5.14.0-687.64.1.el9_8 jest już poprawiona. Dlatego porównuj wersję z komunikatem swojej dystrybucji, nie z tabelą kernel.org.

Według bloga Ubuntu z 2 listopada 2026 roku Canonical wyda je w kieszeni aktualizacji po zakończeniu testów na ponad 2000 certyfikowanych serwerach i urządzeniach. Do tego czasu stosuj mitygacje opisane niżej albo — świadomie — jądro z -proposed. Śledź też stronę CVE-2026-98432 na ubuntu.com.

Red Hat wydał też poprawki dla jądra czasu rzeczywistego RHEL 8 (RHSA-2026:93415) i dla RHEL 9.4 i 8.8 Update Services for SAP Solutions (RHSA-2026:94109, RHSA-2026:94303), a OpenShift Container Platform 4 i 5 mają na 3.11.2026 status „Affected”. Oracle Linux wydał errata dla jąder UEK i RHCK. SUSE wydał poprawki dla części produktów (m.in. SLES 16.0, SLES 15 SP6-LTSS, openSUSE Leap 16.0 i łatki live patching; biuletyny SUSE-SU opublikowane od 29.10.2026), a dla pozostałych, np. SLES 15 SP7, poprawka jest w przygotowaniu (stan ogólny „Pending”, 3.11.2026) — sprawdź komunikaty swojego dostawcy. CERT Polska nie opublikował osobnego komunikatu o CVE-2026-98432 (stan na 3.11.2026); komunikaty dla polskich organizacji śledź na cert.pl.

Kontenery, chmura i Kali Linux

• Kontenery (Docker, Kubernetes) korzystają z jądra hosta — łatać trzeba host lub węzły klastra, nie obraz kontenera (AWS wymienia np. węzły EKS z AMI v20261031 lub nowszym).
• Usługi zarządzane w chmurze łata dostawca (AWS podaje harmonogram m.in. dla RDS i Aurora).
• Kali Linux to dystrybucja rolling. Obraz Kali 2026.3 z 26.10.2026 ma jądro 7.1.5 (gałąź bez poprawki), a według pkg.kali.org w repozytoriach kali-rolling i kali-dev na 3.11.2026 nadal jest linux 7.1.5-1kali1 (bez poprawki). Poprawione jądro 7.2.15-1kali1 trafiło 3.11.2026 tylko do kali-experimental, czyli gałęzi testowej, której nie zalecamy na co dzień. Samo apt full-upgrade jeszcze więc nie usuwa luki. Do tego czasu nie wystawiaj z Kali usług nasłuchujących do niezaufanych sieci albo zastosuj regułę zapory opisaną niżej. Gdy poprawione jądro pojawi się w kali-rolling: zaktualizuj, zrestartuj i sprawdź uname -r (co najmniej 7.2.10 albo dowolny 7.3.x). Więcej o systemie w artykule Kali Linux.

Jak sprawdzić, czy system jest podatny na CVE-2026-98432?

Sprawdź wersję działającego jądra poleceniem uname -r i porównaj ją z wersją z poprawką dla swojej dystrybucji. Jeśli terminal jest dla ciebie nowy, podstawowe polecenia znajdziesz w naszej ściądze z komend Linuksa.

Krok 1. Wersja działającego jądra (każda dystrybucja):

uname -r

Na RHEL i AlmaLinux wynik (np. 5.14.0-687.64.1.el9_8.x86_64) od razu porównasz z tabelą. Na Ubuntu wynik ma postać 6.8.0-149-generic — liczba po myślniku odpowiada pierwszej liczbie po myślniku w numerze pakietu (6.8.0-149.149; na 22.04: 5.15.0-203.213).

Krok 2. Debian: wersja pakietu. Na Debianie uname -r pokazuje numer ABI jądra, a nie pełną wersję pakietu (np. 6.12.113-1). Pełną wersję sprawdzisz w uname -v lub w liście pakietów z kroku 3:

uname -v

Krok 3. Zainstalowane jądra (mogło się już zainstalować, ale nie działa):

# Debian / Ubuntu
dpkg -l 'linux-image-*' | grep '^ii'

# RHEL / AlmaLinux / Fedora / Amazon Linux
rpm -qa 'kernel*'

Jeśli nowe jądro jest na liście, a uname -r pokazuje stare — brakuje tylko restartu.

Krok 4. Czy masz włączone MPTCP i nasłuchujące gniazda MPTCP:

sysctl net.mptcp.enabled
sudo ss -lnMp

Wartość 1 oznacza, że aplikacje mogą tworzyć gniazda MPTCP, a ss -lnMp je pokazuje. Brak MPTCP nie oznacza bezpieczeństwa — błąd siedzi w zwykłym IPv4 TCP.

Skanery podatności (np. Nessus czy OpenVAS) powinny wykryć brakującą poprawkę, jeśli mają wtyczkę dla tego CVE i — najlepiej — skanują z uwierzytelnieniem, czyli z dostępem do listy pakietów.

Jak załatać CVE-2026-98432? Aktualizacja i restart

Jedyna pełna naprawa CVE-2026-98432 to instalacja poprawionego jądra i ponowne uruchomienie systemu. Tak piszą wprost AWS (aktualizacja jądra i restart to jedyna pełna naprawa) i AlmaLinux; zespół CVE jądra zaleca aktualizację do najnowszego stabilnego jądra.

Debian i Ubuntu:

sudo apt update
sudo apt full-upgrade
# Ubuntu: plik pojawia się, gdy restart jest wymagany
cat /var/run/reboot-required 2>/dev/null
sudo reboot

RHEL, AlmaLinux, Rocky Linux, Oracle Linux, Amazon Linux 2023:

sudo dnf upgrade --refresh
# kod wyjścia 1 = potrzebny restart (wtyczka dnf-plugins-core)
sudo dnf needs-restarting -r
sudo reboot

Na Amazon Linux 2 użyj sudo yum update kernel, a potem sudo reboot. Po restarcie ponownie uruchom uname -r. Jeśli nadal widzisz starą wersję, sprawdź, które jądro uruchamia program rozruchowy (GRUB).

Restart na serwerze produkcyjnym

Restart to przerwa w działaniu usług: zaplanuj go w oknie serwisowym, zacznij od systemów wystawionych do internetu, a klastry restartuj węzeł po węźle.

Mitygacje tymczasowe — tylko do czasu aktualizacji

Jeśli poprawione jądro nie jest jeszcze dostępne (np. na Ubuntu w statusie „pending”), dostawcy opisują dwa środki zmniejszające ryzyko:

• Odrzucanie przychodzących pakietów IPv4 TCP z opcjami IP (reguła nftables opublikowana przez Ubuntu; AWS opisuje podobną regułę iptables — odrzuca pakiety IPv4 z opcjami IP). Zwykły ruch TCP działa dalej, bo opcje IPv4 są dziś rzadko używane. Ograniczenie: kontenery z osobną przestrzenią sieciową potrzebują reguły osobno, a AlmaLinux i inżynier zespołu jądra CIQ zwracają uwagę, że ruch między kontenerami na tym samym hoście może filtr ominąć. Reguła nie przetrwa restartu, jeśli nie zapiszesz jej w konfiguracji zapory.
• Wyłączenie MPTCP: sysctl -w net.mptcp.enabled=0 (na stałe: plik w /etc/sysctl.d/) albo GODEBUG=multipathtcp=0 dla programów w Go. Ustawienie blokuje tylko nowe gniazda MPTCP: już otwarte sprawdzisz poleceniem ss -lnMp i zrestartujesz usługi, które je trzymają (AlmaLinux). Usuwa to warunek opisanego exploita, ale nie sam błąd.

Ubuntu zaznacza, że reguła zapory zmniejsza ryzyko, ale nie zapobiega wykorzystaniu w pełni.

Czego CVE-2026-98432 uczy o cyberbezpieczeństwie w czasach AI?

CVE-2026-98432 pokazuje, że AI przyspiesza znajdowanie podatności — i że tym bardziej potrzebni są ludzie, którzy rozumieją, co się dzieje w systemie. Błąd siedział w jądrze od wersji 4.4 (styczeń 2016), czyli od ok. 10 lat. Exploit opisała firma Anthropic, której model Claude napisał go po wstępnych instrukcjach. Ale to ludzie z zespołów jądra, dystrybucji i chmury przygotowali poprawki, ocenili ryzyko (Red Hat i Ubuntu również oznaczyli podatność jako krytyczną) i opisali mitygacje, a na liście oss-security inżynier jądra przeanalizował zgłoszoną na liście mitygację (opcję init_on_free=1) — wspierając się modelem AI — i ocenił, że nie chroni przed tą luką. AI przyspiesza pracę, ale wnioski i decyzje podpisuje człowiek.

AI działa tu jak mocniejszy reflektor: szybciej oświetla słabe miejsca, ale o tym, co naprawić najpierw i jak nie zatrzymać przy tym firmy, decyduje człowiek — szerzej w artykule czy warto uczyć się cyberbezpieczeństwa w czasach AI. Żeby to ocenić, trzeba znać Linuksa, CVSS i eskalację uprawnień.

Jak nauczyć się rozumieć podatności w Linuksie?

Najszybciej nauczysz się tego w laboratorium: najpierw Linux i uprawnienia, potem ocena podatności, a na końcu eksploitacja i eskalacja uprawnień na celach, które wolno atakować. Tak ułożona jest ścieżka w Cyberium — polskim kursie cyberbezpieczeństwa online:

Wszystko ćwiczysz w CyberBoxie, czyli Kali Linux w przeglądarce, bez instalacji — w 57 laboratoriach, przy podziale 80/20 praktyka/teoria i z 5 misjami projektowymi do portfolio i CV. Na końcu jest praktyczny egzamin C:CCE: 12 godzin na test penetracyjny aż do pełnego dostępu administratora i 48 godzin na raport (w bonusie szablony gotowych raportów). Wsparcie eksperta i aktualizacje masz przez cały dostęp. Pisanie exploitów na jądro to dobry kolejny krok po kursie dla osób, które chcą się specjalizować w badaniu podatności.

Advisory i dokumentacja to świetne uzupełnienie, a Cyberium daje do nich kolejność nauki po polsku, gotowe cele i eksperta. Zaczynasz od zera? Zajrzyj do planu jak zacząć naukę cyberbezpieczeństwa w 30 dni, obejrzyj lekcje DEMO albo program kursu cyberbezpieczeństwa od podstaw.

Najczęstsze pytania (FAQ)

Podsumowanie

CVE-2026-98432 to krytyczna podatność jądra Linuksa z października 2026 roku: zdalna, bez uwierzytelnienia, z oceną CVSS 9,8. Poprawki wydały kernel.org, Debian, RHEL, AlmaLinux, Oracle Linux, Amazon Linux i — dla części produktów — SUSE; na Ubuntu są w kieszeni -proposed (stan na 3.11.2026). Sprawdź uname -r, zaktualizuj, zrestartuj, potwierdź; mitygacje stosuj tylko do łatki. Jeśli chcesz rozumieć takie komunikaty i samodzielnie oceniać ryzyko, zacznij od kursu cyberbezpieczeństwa online z laboratoriami po polsku.