30/10/2026 / Cybersecurity /

Luka CVE-2026-98432 w jądrze Linuksa i co zrobić, zanim przyjdzie poprawka

Serwer z Linuksem i ostrzeżenie o krytycznej luce CVE-2026-98432 w obsłudze połączeń TCP

15 października zespół CVE jądra Linuksa opublikował lukę CVE-2026-98432 w obsłudze połączeń TCP po IPv4. Ocena CVSS 3.1 to 9,8 na 10: atak przez sieć, bez konta i bez udziału użytkownika.[1] Poprawka w głównym kodzie jądra już jest, ale 30 października, kiedy to piszemy, Ubuntu i Red Hat Enterprise Linux nie mają poprawionego jądra do zainstalowania.[2][3]

Jeśli Twój system poprawkę już dostał (Debian, Oracle Linux, część SUSE i Amazon Linuksa), zaktualizuj jądro i zrestartuj serwer. Jeśli nie, ogranicz dziś dostęp do serwera z zewnątrz i przygotuj się na aktualizację w dniu, w którym pakiet się pojawi. Żaden producent nie potwierdził obejścia, które w pełni zastąpiłoby poprawkę.

Na czym polega błąd

Połączenie TCP zaczyna się od pakietu SYN, który może nieść opcje IPv4, np. Record Route albo Timestamp. Jądro zapamiętuje je przy rozpoczętym połączeniu, a potem przekazuje nowemu gniazdu bez kopiowania. Jeśli w tej samej chwili inny rdzeń procesora obsługuje powtórzony SYN, może czytać pamięć, którą jądro właśnie zwolniło. To use-after-free wywołany wyścigiem (race condition), a poprawka opóźnia zwolnienie tej pamięci.[1][15]

Błąd siedzi w jądrze od wersji 4.4, czyli od stycznia 2016 roku.[1] RHEL 6 i 7 oraz Ubuntu 14.04 nie są nim objęte.[2][3] W IPv6 główny wariant nie występuje, bo tam opcje są kopiowane. Drugi wariant dotyczy migracji gniazd, działa tylko z włączonym net.ipv4.tcp_migrate_req albo odpowiednim programem BPF, a jego odpowiednik w IPv6 ma dostać osobną poprawkę.[1]

Dlaczego jedni piszą 9,8, a inni 8,1

Zespół jądra i Ubuntu podają 9,8, a Red Hat, Oracle, SUSE i Amazon 8,1.[1][2][3][8][9][10] Różni ich jeden parametr, złożoność ataku (Attack Complexity). Zespół jądra przyjął niską, producenci wysoką, bo napastnik musi trafić w bardzo krótki moment. Nawet 8,1 oznacza zdalny atak bez logowania, z pełnym wpływem na poufność, integralność i dostępność systemu.

Exploit istnieje, ale nie jest publiczny

27 października Anthropic, firma rozwijająca model Claude, opisał exploit, który napisał Claude. Badania prowadzono na wewnętrznym, niewydanym modelu. Exploit daje zdalnemu napastnikowi wykonanie poleceń jako root, bez logowania, na serwerach z nasłuchem Multipath TCP (MPTCP). W próbie Anthropic wyciek adresu z pamięci jądra zajął 48 minut, a wykonanie polecenia kolejne 5. Przegrany wyścig kończy się tylko nieudanym połączeniem, bez awarii systemu, więc napastnik może próbować do skutku.[4]

Kodu exploita ani konfiguracji testowej Anthropic nie ujawnił, a niezależnego odtworzenia tego wyniku nie znaleźliśmy. Red Hat opisuje skutki ostrożniej: przede wszystkim awaria systemu, możliwe uszkodzenie pamięci.[3] Według stanu z 29 października nikt nie zgłaszał ataków w realnych sieciach,[15] a katalog CISA KEV w wersji 2026.10.29 tej luki nie zawierał.[14] Sama poprawka jest jednak publiczna od połowy października, więc każdy może przeczytać, co dokładnie zmieniła. Dlatego nie liczylibyśmy na to, że wykorzystanie tej luki na długo zostanie umiejętnością jednego laboratorium.

Kto ma już poprawione jądro

Stan na 30 października 2026. Zmienia się z dnia na dzień, więc przed decyzją sprawdź stronę swojej dystrybucji, linki są w źródłach.

System Stan
Debian 13 Poprawione: linux 6.12.113-1 (DSA-6568-1)[7]
Debian 12 Poprawione: linux 6.1.190-1 (DLA-4841-1) albo linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1)[7]
Ubuntu 22.04, 24.04, 26.04, 26.10 Podatne, poprawka w przygotowaniu: 5.15.0-203.213, 6.8.0-149.149, 7.0.0-43.43, 7.3.0-10.10[2]
Ubuntu 16.04, 18.04, 20.04 Podatne, bez podanego pakietu[2]
RHEL 8, 9, 10, OpenShift 4 i 5 Podatne, brak poprawki i brak obejścia zatwierdzonego przez Red Hat[3]
AlmaLinux, Rocky Linux Nie znaleźliśmy oficjalnego komunikatu. Traktuj jak podatne i sprawdzaj erraty.
Oracle Linux 7-10 Poprawione jądro UEK, 16.10: ELSA-2026-500397, -500398, -500399[8]
Amazon Linux 2023 Poprawione kernel6.18 (24.10, ALAS2023-2026-3251) i kernel6.12 (29.10, ALAS2023-2026-3335), domyślne jądro czeka[9]
Amazon Linux 2 Czeka na poprawkę[9]
SUSE Poprawione SLES 16.0, SLES 15 SP4-SP6 LTSS, SLE Micro 5.3-5.5 i 6.2 (m.in. SUSE-SU-2026:4934-1, :4936-1, :4937-1), SLES 15 SP7 w toku[10]
Proxmox VE Poprawione w jądrze 7.0.14-25-pve i nowszych, innych gałęzi nie potwierdzono[11]

Jeśli budujesz jądro sam, poprawka jest w wersjach 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 i 7.3.[1] Tych numerów nie porównuj z Ubuntu ani RHEL-em. Te dystrybucje przenoszą poprawki do własnych wersji, więc wynik uname -r zestawiaj z numerem pakietu podanym przez dystrybucję.

Trzy miejsca łatwo pominąć. Kontener używa jądra hosta, więc nowy obraz Dockera niczego nie zmienia i aktualizować trzeba host. VPS na KVM ma własne jądro, które aktualizujesz sam, ale na VPS-ie opartym na kontenerach (OpenVZ, LXC) i na hostingu współdzielonym zależysz od dostawcy, więc zapytaj go o ten CVE. Wiele NAS-ów i routerów też działa na Linuksie. Synology nie ma na dziś komunikatu o tej luce,[17] dla QNAP-a, Ubiquiti i MikroTika też go nie znaleźliśmy. Brak komunikatu nie znaczy, że sprzęt jest bezpieczny, więc panel urządzenia nie powinien być wystawiony do internetu.

Co zrobić dziś

1. Sprawdź, które serwery są osiągalne z zewnątrz

Błąd da się wywołać przez każdą wystawioną usługę TCP, nie tylko przez MPTCP,[6] a zespół bezpieczeństwa ostrzega, że systemy bez nasłuchu MPTCP też mogą być podatne na podobne ataki.[5] Spisz serwery z otwartymi portami i przekierowaniami z routera, oraz na każdym sprawdź jądro i usługi:

uname -r
sudo ss -tlnp

2. Jeśli poprawka jest, zaktualizuj i zrestartuj

# Debian i Ubuntu
sudo apt update && sudo apt full-upgrade

# RHEL, AlmaLinux, Rocky, Oracle Linux, Amazon Linux 2023
sudo dnf upgrade 'kernel*'

# SUSE
sudo zypper patch

# potem zawsze
sudo reboot
uname -r

Bez restartu dalej działa stare jądro, nawet jeśli nowy pakiet jest już zainstalowany. Livepatch liczy się tylko wtedy, gdy producent wprost potwierdzi, że obejmuje ten CVE.[15]

3. Jeśli poprawki nie ma, zamknij dostęp

To najpewniejsze, co można dziś zrobić, bo pakiet, który nie dojdzie do otwartego portu, nie uruchomi błędu. SSH, panele administracyjne i bazy danych schowaj za VPN-em albo za listą dozwolonych adresów na firewallu lub w panelu dostawcy chmury.

Usługi, które muszą być publiczne, np. stronę WWW, możesz postawić za reverse proxy albo load balancerem, który sam kończy połączenia TCP i działa na poprawionym systemie. Serwer za nim ma wtedy przyjmować połączenia tylko od tego proxy. Oba zalecenia wynikają z mechanizmu błędu, producenci ich nie publikują.

4. Rozważ odrzucanie pakietów z opcjami IPv4

Błąd wymaga SYN-a z opcjami IPv4, a RFC 7126 i tak zaleca, żeby routery i firewalle domyślnie odrzucały pakiety z opcjami Timestamp i Record Route.[13] Reguła niżej pochodzi z niezależnych opracowań, nie od producenta. Ich autorzy sprawdzili, że blokuje pakiet wywołujący błąd, ale nie testowali jej na prawdziwym exploicie, bo publicznego nie ma.[12] Red Hat pisze wprost, że żadne dostępne obejście nie spełnia jego kryteriów,[3] więc sprawdź ją najpierw na mniej ważnej maszynie.

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

Reguła znika po restarcie. Nie stosuj jej przy SELinuksie lub Smacku z etykietami CIPSO, bo one korzystają z opcji IP. Na hoście z mostkiem sieciowym, np. w Proxmoksie, nie obejmie ruchu przełączanego do maszyn wirtualnych, więc ustaw ją w każdej maszynie albo na firewallu brzegowym.[12] W RouterOS odpowiada jej reguła z dopasowaniem ipv4-options,[16] którą trzeba przesunąć nad reguły akceptujące:

/ip firewall filter add chain=forward protocol=tcp ipv4-options=any action=drop

5. Sprawdź MPTCP, ale na tym nie poprzestawaj

Od Go 1.24 programy w Go domyślnie nasłuchują na Linuksie przez MPTCP,[5] więc taki nasłuch może istnieć bez niczyjej świadomej decyzji. Sprawdzisz to tak:

sysctl net.mptcp.enabled
sudo ss -Mlnp

Jeśli MPTCP nie jest Ci potrzebny, wyłącz go poleceniem sudo sysctl -w net.mptcp.enabled=0 i zrestartuj usługi, bo otwarte już nasłuchy zostają przy MPTCP.[12] Dla jednego programu w Go wystarczy zmienna GODEBUG=multipathtcp=0.[5] Usuwa to tylko scenariusz z pokazu Anthropic, a nie sam błąd. Zespół Go nazywa wyłączanie w poszczególnych programach kruchym obejściem, a zgłaszający w trackerze Fedora CoreOS wycofał tę mitygację, między innymi dlatego, że ustawienie działa osobno w każdej przestrzeni nazw, więc samo wyłączenie na hoście nie wystarcza.[5][6]

6. Przejrzyj logi jądra

sudo journalctl -k | grep -E 'ip_options_build|ip_build_and_send_pkt|skb_under_panic'

Awaria z takim śladem to powód, żeby przyjrzeć się serwerowi.[15] Czyste logi niczego nie dowodzą, bo przegrany wyścig nie musi skończyć się awarią.[4]

Jak szybko zaktualizować, kiedy poprawka wyjdzie

Ani Canonical, ani Red Hat nie podają terminu, więc trzeba pilnować tego samemu. Zalecamy, żeby serwery wystawione do internetu dostały poprawkę tego samego dnia, a pozostałe w ciągu 48 godzin. Żeby to się udało, zrób teraz cztery rzeczy:

  1. Obserwuj stronę swojej dystrybucji. Ubuntu i Red Hat mają strony tego CVE w źródłach, dla pochodnych RHEL-a sprawdzaj errata AlmaLinux i errata Rocky Linux. Zapisz się też na listę ubuntu-security-announce albo włącz powiadomienia o erratach w Red Hat Customer Portal.
  2. Uzgodnij okno restartu już dziś. Ustal godzinę, zrób kopię, którą da się odtworzyć, i upewnij się, że usługi startują same po restarcie.
  3. Sprawdzaj dostępność pakietu z serwera. Polecenia są niżej.
  4. Sprawdź automatyczne aktualizacje. Unattended-upgrades i dnf-automatic mogą zainstalować pakiet, ale stare jądro działa do restartu, a automatyczny restart często nie jest włączony.
# Debian i Ubuntu
sudo apt update && apt list --upgradable | grep linux-image

# RHEL i pochodne
sudo dnf updateinfo list --cve CVE-2026-98432

Po aktualizacji i restarcie porównaj uname -r z wersją podaną przez dystrybucję i dopiero wtedy usuń tymczasową regułę. Przywróć też MPTCP, jeśli jest potrzebny.

sudo nft delete table ip cve_2026_98432

Nie wiesz, ile masz takich maszyn ani co z nich widać z internetu? Pomagamy małym i średnim firmom w Krakowie i zdalnie: sprawdzamy wystawione usługi, ustawiamy firewall i VPN oraz planujemy aktualizacje w ramach usług bezpieczeństwa.

Źródła

  1. Linux kernel CVE team, „CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period”, 15.10.2026: ogłoszenie, rekord CVE, poprawka w jądrze.
  2. Ubuntu Security, CVE-2026-98432, aktualizacja 29.10.2026: ubuntu.com/security/CVE-2026-98432.
  3. Red Hat, CVE-2026-98432: strona CVE, Bugzilla 2553390, stan z 30.10.2026.
  4. Anthropic, „Discovering and exploiting vulnerabilities in critical, real-world software with Claude”, 27.10.2026: anthropic.com.
  5. Go Security Team, „Protecting against CVE-2026-98432”: golang-announce; informacje o wydaniu Go 1.24: go.dev/doc/go1.24.
  6. Fedora CoreOS tracker, zgłoszenie 2249, 30.10.2026: github.com/coreos/fedora-coreos-tracker/issues/2249.
  7. Debian Security Tracker: security-tracker.debian.org/tracker/CVE-2026-98432.
  8. Oracle Linux, CVE-2026-98432: linux.oracle.com/cve/CVE-2026-98432.html.
  9. Amazon Linux Security Center, CVE-2026-98432: explore.alas.aws.amazon.com.
  10. SUSE, CVE-2026-98432, aktualizacja 30.10.2026: suse.com/security/cve/CVE-2026-98432.html.
  11. Forum Proxmox, „CVE-2026-98432 in Proxmox VE”: forum.proxmox.com.
  12. Niezależne opracowania filtra opcji IPv4, bez potwierdzenia producentów: getrff.com, typhoon1217/cve-2026-98432-mitigation.
  13. RFC 7126 (BCP 186), „Recommendations on Filtering of IPv4 Packets Containing IPv4 Options”: rfc-editor.org/rfc/rfc7126.
  14. CISA, Known Exploited Vulnerabilities Catalog, wersja 2026.10.29: cisa.gov.
  15. Rescana, zestawienie stanu poprawek i warunków ataku, 29.10.2026: rescana.com.
  16. MikroTik, RouterOS, „Common Firewall Matchers and Actions”: help.mikrotik.com.
  17. Synology, Security Advisory, stan z 30.10.2026: synology.com/security/advisory.

Najczęściej zadawane pytania

Czy luka CVE-2026-98432 jest już wykorzystywana w atakach?
Według stanu z 29 października 2026 nikt nie zgłaszał ataków w realnych sieciach, a katalog CISA KEV w wersji 2026.10.29 jej nie zawierał. Anthropic opisał działający exploit, ale go nie opublikował. Poprawka jest publiczna od połowy października, więc ten stan może się zmienić.
Czy wyłączenie MPTCP wystarczy?
Nie. Usuwa tylko scenariusz z pokazu Anthropic. Sam błąd jest w obsłudze zwykłych połączeń TCP po IPv4, a zespół bezpieczeństwa Go ostrzega, że systemy bez nasłuchu MPTCP też mogą być podatne na podobne ataki. Pewnym rozwiązaniem jest dopiero poprawione jądro i restart.
Czy Docker chroni przed tą luką?
Nie. Kontener korzysta z jądra hosta, więc aktualizacja obrazu niczego tu nie zmienia. Poprawione jądro trzeba zainstalować na hoście i zrestartować host.
Czy serwery z IPv6 są bezpieczne?
Główny wariant błędu dotyczy tylko IPv4, bo w IPv6 opcje są kopiowane. Wariant związany z migracją gniazd ma w IPv6 dostać osobną poprawkę. Jeśli serwer przyjmuje też połączenia po IPv4, a zwykle przyjmuje, nadal jest narażony.
Dlaczego luka ma ocenę 9,8, a Red Hat podaje 8,1?
Różni je złożoność ataku. Zespół jądra przyjął niską, a Red Hat, Oracle, SUSE i Amazon wysoką, bo napastnik musi trafić w bardzo krótki moment. W obu przypadkach to zdalny atak bez logowania.