Luka w jądrze Linuksa CVE-2026-98432: Ubuntu LTS bez łatki w aktualizacjach. Co zrobić z firmowym VPS-em

W tym tekście w 15 minut sprawdzisz, czy Twój firmowy VPS jest narażony na lukę CVE-2026-98432 i co zrobić, zanim Ubuntu wyda poprawkę. Luka w jądrze Linuksa ma ocenę 9,8 na 10 w skali CVSS i pozwala zaatakować serwer zdalnie, bez logowania. Red Hat, AlmaLinux i Debian już ją załatały. Ubuntu LTS (22.04, 24.04, 26.04) na 3 listopada 2026 nie ma łatki w zwykłych aktualizacjach: poprawione jądra są dopiero w testach, a Canonical nie podał daty wydania (Canonical, Ubuntu).

Do czasu łatki masz dwa ruchy: tymczasową regułę firewalla, którą Ubuntu opublikowało na stronie luki, i wyłączenie multipath TCP (MPTCP). Oba zmniejszają ryzyko, żaden nie usuwa błędu. Zespół bezpieczeństwa Ubuntu za jedyną właściwą ochronę uważa aktualizację jądra (Canonical). Gdy łatka trafi do aktualizacji: instalujesz ją i restartujesz serwer.

Pilne, ale bez paniki: działający exploit Anthropic nie jest publiczny, a luki nie ma w katalogu CISA KEV (amerykańskiej liście luk wykorzystywanych w realnych atakach), więc nie ma potwierdzonych ataków.

Co się stało: luka CVE-2026-98432 w skrócie

Jądro Linuksa to rdzeń systemu, który obsługuje między innymi połączenia sieciowe. W kodzie nawiązywania połączeń IPv4 TCP (tzw. handshake) jest błąd typu use-after-free: jądro sięga do pamięci, którą już zwolniło. Da się go wykorzystać zdalnie i bez logowania, zanim połączenie dotrze do jakiejkolwiek aplikacji (Atlas, Ubuntu).

Błąd sięga Linuksa 4.4. Skutki według opisu CVE to wyciek pamięci jądra do atakującego, uszkodzenie pamięci albo awaria serwera. Red Hat dopisuje zdalne wykonanie kodu. Lukę zgłosił Xinyang Ge z Anthropic, a poprawka Erica Dumazeta ma cztery linie: zamienia kfree() na kfree_rcu() (Atlas).

Anthropic opisał, że Claude napisał działający exploit dający uprawnienia roota (pełną kontrolę nad serwerem) na serwerach Linux z listenerem multipath TCP, bez żadnych danych logowania (Atlas, Sekurak). Listener to program, który nasłuchuje na porcie i czeka na połączenia. Wyciek wskaźnika jądra zajmował 48 minut, wykonanie komend kolejne 5. Nieudana próba nie wywala serwera, więc atakujący może ją ponawiać do skutku (Atlas).

Narażony jest każdy serwer z podatnym jądrem, który przyjmuje połączenia IPv4 TCP: strona WWW, SSH, baza danych, load balancer, węzeł Kubernetesa (Atlas). W praktyce to każdy firmowy VPS z podatnym jądrem i publicznym adresem IPv4.

Jak pilna jest luka CVE-2026-98432?

Pilna, bo 9,8 na 10 to poziom krytyczny, do ataku nie trzeba hasła, a Ubuntu 3 listopada podniosło priorytet luki do „Critical” (Ubuntu). Powodu do paniki jednak nie ma:

• Exploit Anthropic nie jest publiczny. Canonical pisze, że poza nim nie zna innego exploita (Canonical).
• Publiczne repozytoria to na razie warsztat, nie broń. Na GitHubie 66 repozytoriów odnosi się do tej luki (stan na 3 listopada), co najmniej 9 deklaruje kod wywołujący błąd albo proof of concept (dowód, że atak działa). Najnowsze z „root-shell” w opisie to „lab root-shell kit” z 2 listopada, który wymaga zmodyfikowanego jądra. Repozytoria z 3 listopada to głównie narzędzia do audytu i ochrony (Atlas, GitHub).
• Brak potwierdzonych ataków. W katalogu CISA KEV tej luki nie ma, a jego najnowsza wersja pochodzi z 30 października (CISA KEV, Atlas).

Wniosek: masz czas, żeby spokojnie sprawdzić serwer dziś. Nie masz czasu, żeby odłożyć to na przyszły miesiąc.

Czy luka w jądrze Linuksa dotyczy mojego serwera?

To zależy od dwóch rzeczy: kto zarządza jądrem i jaki system działa na serwerze.

Kto aktualizuje jądro: Ty czy dostawca?

Na dzień publikacji nie znaleźliśmy komunikatów o tej luce u OVH, cyber_Folks, home.pl, Mikrusa ani Hetznera (sprawdzaliśmy 3 listopada rano i wieczorem). Zakładaj więc, że jądro na swoim VPS-ie aktualizujesz Ty. Własny serwer to także obowiązek pilnowania aktualizacji, o czym pisaliśmy przy porównaniu Make i n8n.

Docker nie chroni przed luką w jądrze

Kontener Dockera działa na jądrze serwera, na którym stoi. Nowy obraz Dockera ani aktualizacja n8n tej luki nie zamykają, bo błąd siedzi w jądrze pod spodem. Dlatego komendy z tego tekstu uruchamiasz na samym serwerze, nie w kontenerze (Atlas).

Status łatki w dystrybucjach Linuksa

Źródła: Ubuntu, Canonical i Launchpad (Ubuntu), Atlas (pozostałe systemy).

Ubuntu to popularny wybór na tanie VPS-y i pod instalację n8n. Luka trafia więc akurat tam, gdzie w małych firmach często działają automatyzacje.

n8n, Caddy i Traefik: skąd się bierze multipath TCP?

Multipath TCP (MPTCP) to rozszerzenie TCP, dzięki któremu jedno połączenie może korzystać z kilku ścieżek sieciowych naraz. Exploit Anthropic potrzebował programu nasłuchującego przez MPTCP. Od 29 października wiadomo, że programy w Go od wersji 1.24 otwierają takie listenery domyślnie, jeśli jądro na to pozwala (Atlas).

Samo n8n działa na Node.js, więc domyślne zachowanie Go go nie dotyczy. Ale przed n8n często stoi reverse proxy (program, który przyjmuje ruch z internetu i przekazuje go dalej), np. Caddy albo Traefik. Oba są napisane w Go.

3 listopada sprawdziliśmy ich repozytoria na GitHubie: w gałęzi głównej Caddy deklaruje Go 1.26.0, a Traefik Go 1.27.0 (Caddy go.mod, Traefik go.mod). To nie przesądza o Twoim serwerze. Program może nadpisać domyślne ustawienie, a wersja zainstalowana u Ciebie nie musi odpowiadać gałęzi głównej. Jeśli masz Caddy albo Traefika, sprawdź serwer komendą ss -Mlnp z kroku 2.

Sprawdź serwer w 5 minut

Krok 1. Jaki system i jakie jądro (2 minuty)

Nazwę i wersję systemu (np. Ubuntu 24.04 albo AlmaLinux 9) zobaczysz w panelu dostawcy VPS. Wersję jądra sprawdzisz na serwerze (Atlas):

uname -r                          # działające jądro
dpkg -l 'linux-image*' | grep ^ii # Debian/Ubuntu: zainstalowane pakiety jądra
rpm -q kernel                     # RHEL, AlmaLinux i pochodne: zainstalowane jądra
needs-restarting -r               # RHEL (dnf-utils): czy trzeba restartu?

Jak czytać wynik:

• Porównuj ze statusem swojej dystrybucji, nie z numerami z wiadomości. Dystrybucje mają własną numerację jąder, np. Ubuntu 24.04 ma jądra 6.8.0-xxx. Z numerami poprawionych jąder w wersji oficjalnej, takimi jak 6.12.113 czy 6.6.159, nie da się ich zestawić wprost.
• Zainstalowane jądro jest nowsze niż działające? Poprawka jeszcze nie działa. Zacznie po restarcie serwera.
• Masz Dockera albo Kubernetesa? Komendy uruchamiasz na hoście, nie w kontenerze.
• Na Ubuntu LTS w zwykłych aktualizacjach nie ma dziś poprawionego jądra. Zakładaj, że Twoje jest podatne. Numery z tabeli niżej przydadzą się, gdy łatka trafi do aktualizacji.

Przykład: na Ubuntu 24.04 wynik uname -r niższy niż 6.8.0-149 (np. 6.8.0-147-generic) oznacza jądro bez poprawki. Jądra chmurowe, czyli warianty dla AWS, Azure, GCP i innych, mają własne numery i też czekają na poprawkę (Ubuntu, Launchpad).

Krok 2. Czy coś nasłuchuje przez MPTCP (2 minuty)

sudo ss -Mlnp             # gniazda MPTCP i procesy, które je otwarły
sysctl net.mptcp.enabled  # 1 = aplikacje mogą otwierać gniazda MPTCP

Jak czytać wynik (Atlas):

• ss -Mlnp pokazuje tylko wiersz nagłówka, bez kolejnych wierszy? To znaczy, że nic nie nasłuchuje przez MPTCP. Exploit Anthropic opisano dla serwerów z takim listenerem, więc ryzyko jest mniejsze. Nie zerowe, bo jądro nadal jest podatne.
• net.mptcp.enabled = 1 samo w sobie listenera nie tworzy. Oznacza tylko, że programy mogą go otworzyć.
• Widzisz pod nagłówkiem wiersz z nazwą procesu? Taki serwer łata się w pierwszej kolejności i nie wystawia do internetu. Na Ubuntu LTS łatki w aktualizacjach jeszcze nie ma, więc od razu przejdź do reguły tymczasowej i wyłączenia MPTCP (niżej), a z administratorem ustal, czy da się ograniczyć dostęp do tego serwera z internetu.

Masz Debiana, RHEL, AlmaLinux albo inny system z łatką: aktualizacja i restart

Dotyczy też Oracle Linux, Amazon Linux, części wersji SUSE i Ubuntu 26.10. Zainstaluj poprawione jądro z repozytorium swojej dystrybucji i zrestartuj serwer. Restart nie jest tu formalnością: nowe jądro działa dopiero wtedy, gdy serwer na nim wystartuje (Atlas).

Po restarcie sprawdź jeszcze raz uname -r, a na RHEL i pochodnych także needs-restarting -r. Restart to krótka przerwa w działaniu n8n, sklepu albo CRM-u, więc zaplanuj go poza godzinami największego ruchu i sprawdź potem, czy wszystkie usługi wstały, w tym kontenery Dockera.

Masz Ubuntu LTS: co zrobić, zanim łatka trafi do aktualizacji

1. Załóż regułę tymczasową z trackera Ubuntu

Na stronie luki Ubuntu opublikowało sekcję „Mitigation” z regułą dla nftables, czyli wbudowanego w Linuksa firewalla. Reguła odrzuca przychodzące pakiety IPv4 TCP z tzw. opcjami IP (dodatkowymi polami w nagłówku pakietu). Zwykły ruch działa dalej, przestają działać tylko połączenia, które korzystają z opcji IP. Ubuntu zaznacza, że reguła zmniejsza ryzyko, ale nie zapobiega atakowi w pełni (Ubuntu).

printf '%s\n' 'table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}' | sudo tee /etc/cve-2026-98432.nft >/dev/null
sudo nft -c -f /etc/cve-2026-98432.nft && sudo nft -f /etc/cve-2026-98432.nft

Pierwsza komenda zapisuje regułę do pliku. Druga sprawdza jej składnię i dopiero wtedy ją wczytuje.

Żeby reguła przetrwała restart serwera, Ubuntu podaje dwie kolejne komendy:

echo 'include "/etc/cve-2026-98432.nft"' | sudo tee -a /etc/nftables.conf
sudo nft -c -f /etc/nftables.conf && sudo systemctl enable nftables.service

Uwaga: ta część zakłada, że firewallem zarządza plik /etc/nftables.conf, a na serwerze nie działa UFW ani firewalld (Ubuntu). Jeśli Twój VPS korzysta z UFW albo firewalld, nie wklejaj tych dwóch komend na ślepo. Niech administrator ustali, jak dodać regułę na stałe w Twojej konfiguracji.

Gdy reguła przestanie być potrzebna, np. po instalacji poprawionego jądra i restarcie, wycofasz ją dwiema komendami z tej samej sekcji Ubuntu. Pierwsza usuwa wpis z /etc/nftables.conf, druga zdejmuje regułę z działającego firewalla:

sudo sed -i '\|^include "/etc/cve-2026-98432.nft"$|d' /etc/nftables.conf
sudo nft delete table inet cve_2026_98432

Kontenery z osobną siecią wymagają osobnej reguły (Ubuntu). Masz n8n w Dockerze? Przekaż administratorowi też wariant od AlmaLinux opisany przez Atlas: łapie ruch kierowany do kontenerów, ale znika po restarcie, a ruch między kontenerami przez most sieciowy Dockera może go omijać.

2. Wyłącz MPTCP, jeśli go nie używasz

Wyłączenie multipath TCP zmniejsza ryzyko, bo zamyka drogę, którą wykorzystał exploit Anthropic. Ale nie naprawia luki. Błąd siedzi w zwykłym IPv4 TCP, a Go Security Team ostrzega, że systemy bez listenerów MPTCP mogą być podatne na podobne ataki (Atlas). Zespół bezpieczeństwa Ubuntu pisze wprost, że wyłączenie MPTCP nie wystarcza (Canonical).

Kroki według AlmaLinux (Atlas):

echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0
sudo ss -Mlnp   # listenery otwarte wcześniej zostają MPTCP: zrestartuj te usługi

Dwie pułapki:

• Listenery otwarte przed zmianą zostają. Zrestartuj usługi, które pokazało ss -Mlnp.
• Docker ma osobne ustawienie. net.mptcp.enabled działa osobno w każdej przestrzeni sieciowej, więc kontenery trzeba ustawić oddzielnie, np. parametrem --sysctl net.mptcp.enabled=0.

Nie wiesz, czy coś w firmie korzysta z MPTCP? Zapytaj administratora, zanim je wyłączysz.

3. Zapytaj dostawcę o firewall brzegowy

Jeśli dostawca VPS ma firewall przed serwerami i potrafi odrzucać pakiety IPv4 z opcjami IP, reguła ustawiona tam chroni naraz wszystkie serwery za nim (Atlas).

4. Czekaj na aktualizację, a po niej zrestartuj serwer

Canonical pisze, że poprawki dla Ubuntu 22.04 i nowszych przechodzą testy na ponad 2000 certyfikowanych serwerach i urządzeniach. Do zwykłych aktualizacji trafią po zakończeniu testów, ale daty Canonical nie podał (Canonical).

Gdy przy aktualizacji systemu pojawi się jądro z numerem z tabeli w kroku 1 (albo wyższym), zainstaluj je i zrestartuj serwer. Bez restartu łatka nie działa.

Śledź post Canonical i tracker Ubuntu. Tracker bywa spóźniony: dla 26.10 wciąż pokazuje „Vulnerable”, choć poprawione jądro jest już w aktualizacjach.

Dla administratora: jądro z -proposed. Kto sam testuje jądra, może zainstalować poprawione jądro już teraz z testowego repozytorium -proposed. Komendy są w poście Canonical, a po instalacji trzeba zrestartować serwer. Canonical kieruje tę opcję do osób, które testują jądra na własną rękę. Jeśli nie masz administratora, poczekaj na zwykłą aktualizację i do tego czasu trzymaj się kroków 1–3.

Czy to prawda, że luka wymaga niedomyślnych ustawień i jest już załatana?

Dla Ubuntu LTS nie. Taki obraz pojawił się w polskich mediach: Sekurak 30 października napisał, że podatność wymaga listenera MPTCP, „co nie jest domyślne”, i że została załatana (Sekurak). Dla właściciela VPS-a z Ubuntu LTS oba wnioski są dziś mylące, z dwóch powodów:

1. MPTCP bywa domyślne. Go Security Team poinformował 29 października, że programy w Go od wersji 1.24 otwierają listenery MPTCP domyślnie (Atlas).
2. Łatka nie jest wszędzie. Poprawka jest w oficjalnym jądrze Linuksa i u części dystrybucji. W Ubuntu LTS na 3 listopada jest tylko w testowym -proposed, bez daty wydania (Canonical, freenode).

Nie jesteś adminem? Wyślij te pytania osobie, która stawiała serwer

Jeśli VPS konfigurował Ci freelancer albo agencja, wyślij im link do trackera Ubuntu i te pytania:

1. Jaki system i jakie jądro działa na naszym serwerze (wynik uname -r)?
2. Czy coś nasłuchuje przez MPTCP (wynik sudo ss -Mlnp)?
3. Czy reguła tymczasowa Ubuntu jest założona i czy przetrwa restart, także przy UFW albo firewalld?
4. Czy MPTCP jest wyłączone, również w kontenerach?
5. Kto i kiedy zainstaluje poprawione jądro i zrestartuje serwer, gdy łatka trafi do zwykłych aktualizacji Ubuntu?

Dostawcę VPS zapytaj o dwie rzeczy: jaki to typ VPS-a (czy jądro jest Twoje, czy jego) i czy jego firewall potrafi odrzucać pakiety IPv4 z opcjami IP.

Podobne checklisty dawaliśmy przy fałszywym rozszerzeniu Claude Code w Cursorze i przy krytycznych lukach w PHP.

FAQ

Czy Ubuntu 24.04 ma łatkę na CVE-2026-98432?

W zwykłych aktualizacjach nie. Poprawione jądro 6.8.0-149.149 jest od 26 października tylko w testowym repozytorium -proposed, a w aktualizacjach bezpieczeństwa wciąż jest 6.8.0-147.147. Canonical nie podał daty wydania. Do tego czasu zostaje reguła tymczasowa Ubuntu i wyłączenie MPTCP.

Czy wyłączenie MPTCP wystarczy?

Nie. Wyłączenie multipath TCP zmniejsza ryzyko, ale błąd w jądrze siedzi w zwykłym IPv4 TCP. Zespół bezpieczeństwa Ubuntu za jedyną właściwą ochronę uważa aktualizację jądra, a po niej restart serwera.

Czy hosting współdzielony jest narażony?

Tak, jeśli serwer dostawcy działa na podatnym jądrze, bo przyjmuje połączenia WWW przez IPv4 TCP. Jądro aktualizuje tam jednak dostawca, nie Ty: zapytaj go, kiedy załata lukę.

Czy luka CVE-2026-98432 dotyczy IPv6?

Główny błąd dotyczy tylko IPv4 (Ubuntu). To nie jest sposób na ochronę: dopóki serwer przyjmuje połączenia IPv4 TCP, pozostaje narażony.

---

Masz n8n, sklep albo CRM na własnym VPS-ie i nie wiesz, kto u Ciebie pilnuje aktualizacji jądra? Umów bezpłatną konsultację z B2B Solution.