CVE-2026-98432 i CVE-2026-106378: poprawki Linuksa i Chrome

CVE-2026-98432 dotyczy obsługi TCP przez IPv4 w jądrze Linuksa; CVE-2026-106378 dotyczy piaskownicy Chrome na macOS w wersjach przeglądarki starszych niż 155.0.8059.39. Sprawdź hosty z Linuksem według komunikatu dostawcy jądra, a przeglądarki na Macach według informacji o aktualizacjach Chrome. Po aktualizacji potwierdź aktywną wersję: samo pobranie pakietu nie dowodzi, że którakolwiek z poprawek już działa.

O problemie Linuksa przypomniało operatorom serwerów, węzłów i przekaźników ostrzeżenie Dereka Rossa z 30 października. Wpis PWN.AI z 30 października zwraca uwagę na osobną podatność pozwalającą opuścić piaskownicę procesu GPU w Chrome. Zespół startupu musi teraz ustalić, które maszyny, pakiety i instalacje przeglądarki wymagają działania.

Linuksowy komunikat o CVE pochodzi z 15 października, a Google opublikował rekord CVE dotyczący Chrome 6 października. Dzisiejsze wpisy ponownie zwracają uwagę na znane już podatności i poprawki.

Stan sprawdzony 30 października 2026 r. Aktualnych informacji szukaj w podlinkowanych niżej źródłach dostawców. Dostępność pakietów może się zmienić po publikacji tego zestawienia.

Czym jest CVE-2026-98432 i czy pozwala zdalnie przejąć serwer?

Potwierdzony błąd dotyczy czasu życia pamięci podczas obsługi połączeń TCP. To poważna podatność jądra. Twierdzenia o niezawodnym zdalnym przejęciu wymagają jednak osobnego potwierdzenia.

Use-after-free oznacza odwołanie do pamięci, która została już zwolniona. W tym przypadku równoległe operacje mogą nadal odczytywać opcje gniazda IPv4, choć inna ścieżka wykonania zdążyła je zwolnić.

Poprawka w głównym repozytorium jądra zmienia dwie ścieżki zwalniania pamięci: odracza operację do zakończenia okresu ochronnego RCU. Read-copy-update, czyli RCU, to mechanizm jądra, który pozwala trwającym odczytom zakończyć się przed odzyskaniem pamięci.

Podczas weryfikacji 30 października Ubuntu podawało ocenę CVSS 3.1 równą 9.8, a aktualny komunikat Red Hat również zawierał wstępną ocenę 9.8. Red Hat opisuje możliwość awarii systemu, odmowy usługi lub uszkodzenia pamięci. Amazon Linux ocenia podatność na 8.1. Przy każdej ocenie podaj dostawcę i wersję metody CVSS. Sama punktacja nie dowodzi, że każdą podatną instalację da się niezawodnie przejąć.

W badaniu Anthropic z 27 października opisano demonstrację exploita wykonującego polecenia jako root na serwerze Linux z gniazdem nasłuchującym Multipath TCP (MPTCP), bez danych logowania i interakcji użytkownika. To demonstracja zdalnego wykonania kodu w określonej konfiguracji. Nie potwierdza niezawodności ataku na każdym podatnym jądrze i w każdym wdrożeniu.

Komunikat zespołu bezpieczeństwa Go z 29 października wyjaśnia, skąd mogą się brać nieoczekiwane gniazda tego typu: Go 1.24 domyślnie włącza MPTCP w gniazdach nasłuchujących w Linuksie. Aplikacja i ustawienia środowiska wykonawczego mogą zmienić tę wartość. Zespół zaleca poprawione jądro i ostrzega, że wyłączenie MPTCP blokuje zademonstrowaną ścieżkę ataku, ale nie usuwa podstawowego błędu IPv4.

W dokumentacji incydentu rozdziel trzy pytania: czy podatny kod jest obecny, czy dociera do niego odpowiedni ruch i jakie wykorzystanie błędu wykazano w twojej konfiguracji? Nie trzeba czekać na komplet odpowiedzi, by nadać aktualizacji priorytet. Brak odpowiedzi nie potwierdza ani bezpieczeństwa, ani włamania.

Które wersje jądra Linuksa są podatne, a które mają poprawkę?

Numery wydań projektu Linux wskazują poprawki w jego poszczególnych gałęziach. Pakiety dystrybucji wymagają osobnej weryfikacji, bo dostawca może przenieść poprawkę do starszej wersji bazowej, zachowując jej numer.

Według aktualnego rekordu Linux CNA błąd pojawił się w Linux 4.4. Rekord wskazuje następujące pierwsze poprawione wydania, sprawdzone 30 października:

Korzystaj z najnowszego wspieranego wydania utrzymywanej gałęzi. Tabela opisuje wydania projektu Linux, a nie uniwersalną regułę wykrywania podatności w Ubuntu, Debianie, RHEL czy obrazie chmurowym. To komunikat dostawcy określa, które pakiety dystrybucji zawierają zmianę.

Backport to przeniesienie poprawki do utrzymywanej starszej bazy kodu. Dlatego pakiet z pozornie niższym numerem wersji może już zawierać zmianę. Samo sprawdzenie, czy wynik uname -r jest liczbowo wyższy od wersji podanej w mediach społecznościowych, może prowadzić do błędnej oceny maszyny.

Zapisz pełne oznaczenie pakietu: wydanie dystrybucji, rodzinę lub wariant jądra, architekturę i rewizję pakietu. Jądra chmurowe, ogólnego przeznaczenia i przeznaczone do obsługi nowszego sprzętu mogą mieć różne ścieżki aktualizacji w tej samej dystrybucji.

Zgodnie z opisem projektu Linux pierwszy problem nie dotyczy IPv6, ale występuje pokrewny błąd migracji żądań IPv6, który ma naprawić osobna zmiana. Przeniesienie usługi na IPv6 nie oznacza więc rozwiązania wszystkich istotnych problemów jądra. Sprawdź komunikat dotyczący własnej konfiguracji.

Jaki jest stan poprawek w Ubuntu, Debianie, RHEL i środowiskach chmurowych?

Status poprawki dotyczy konkretnego produktu i linii pakietów. Tabela przedstawia stan z podanej daty i pomaga znaleźć właściwą pozycję. Nie potwierdza stanu działającego hosta.

Źródła: tracker CVE Ubuntu, tracker bezpieczeństwa Debiana, tracker CVE Amazon Linux, komunikat Red Hat oraz repozytorium CVE Oracle Linux.

Podane numery Debiana to wersje pakietów źródłowych. Nie oczekuj identycznych wartości w wyniku uname -r.

Tracker Ubuntu obejmuje wiele dodatkowych wariantów. Komunikaty Oracle dotyczące UEK nie potwierdzają poprawienia wszystkich linii jąder Oracle.

Jeśli w zestawieniu nie ma twojego dokładnego pakietu, otwórz tracker dostawcy. Do czasu ustalenia właściwej pozycji oznacz status jako nieznany. Brak w krótkiej tabeli artykułu nie jest dowodem bezpieczeństwa.

Jak sprawdzić, z którym jądrem rzeczywiście działa serwer?

Najpierw ustal system operacyjny i uruchomione wydanie jądra. Dopiero potem powiąż te dane z wykazem pakietów dostawcy.

Na hoście z Linuksem zacznij od poleceń, które tylko odczytują informacje:

cat /etc/os-release
uname -r

Zapisz wynik razem z identyfikatorem hosta i czasem sprawdzenia. Ustal też, kto odpowiada za aktualizacje jądra. W usłudze zarządzanej może to wymagać potwierdzenia od dostawcy zamiast dostępu do menedżera pakietów.

Polecenia wykonuj w środowisku, którego jądro chcesz zweryfikować.

Narzędziami swojej dystrybucji sprawdź zainstalowane pakiety jądra i ich pełne rewizje. Właściwy pakiet porównaj z poprawioną kompilacją wskazaną przez dostawcę. Pomyślny wynik menedżera pakietów dokumentuje instalację, ale nadal trzeba ustalić, które jądro działa.

Rozróżniaj te stany:

Po zwykłej aktualizacji jądra wykonaj restart zgodnie z procedurą dostawcy i ponownie sprawdź uruchomioną wersję. Przy poprawkach nakładanych bez restartu, czyli live patchingu, uzyskaj wyraźne potwierdzenie, że dostawca obejmuje tę CVE na tym jądrze. Sam abonament na taką usługę nie wystarcza.

Tak samo sprawdzaj maszyny zastępcze: najpierw obraz lub szablon nowych hostów, potem świeżo uruchomioną instancję. Inaczej aktualizacja dzisiejszych serwerów może się udać, a jutrzejsza maszyna zastępcza pozostanie niezweryfikowana.

Co zrobić, gdy dostawca nie udostępnił jeszcze poprawki?

Ogranicz istotne możliwości dotarcia do podatnego kodu, wskaż osobę odpowiedzialną za kolejną decyzję i wyraźnie oznacz brak poprawki. Środki tymczasowe wymagają osobnej weryfikacji oraz planu wycofania.

Zacznij od spisu hostów i ich dostępności z sieci: które hosty przyjmują połączenia TCP, z jakich sieci i przez jakie zabezpieczenia? Oprócz publicznej usługi uwzględnij interfejsy administracyjne i usługi infrastruktury. Sama nazwa hosta nie opisuje drogi ruchu sieciowego do maszyny.

Sprawdź, czy zbędne usługi można wyłączyć albo zawęzić do nich dostęp bez zakłócania potrzebnych funkcji. Opisz dokładnie, które sieci źródłowe nadal mogą dotrzeć do którego gniazda nasłuchującego. Zweryfikuj to z odpowiedniego miejsca w sieci. Zapisz uzyskane ograniczenie ekspozycji i pozostałe ryzyko.

Według komunikatu Red Hat żaden dostępny środek zaradczy nie spełnia obecnie opublikowanych kryteriów przydatności. Zespół CVE jądra Linuksa zaleca aktualizację do wspieranego stabilnego wydania i odradza wybieranie pojedynczych poprawek. Korzystaj ze wspieranej ścieżki dostawcy zamiast samodzielnie przygotowywać zmianę jądra.

Ostrzeżenie w mediach społecznościowych wspomina też filtrowanie opcji IPv4 i wyłączenie Multipath TCP, czyli MPTCP. Komunikat Go potwierdza potrzebę sprawdzenia gniazd nasłuchujących MPTCP, ale ostrzega, że konfigurowanie każdego programu osobno jest zawodne, a podstawowy błąd nie ogranicza się do MPTCP. Przed użyciem obejścia ustal, której ścieżki kodu dotyczy, jaki ruch nadal dociera do hosta i czy dostawca wspiera je w twojej konfiguracji.

Zmianę reguł sieciowych powinna zatwierdzić osoba odpowiedzialna za tę sieć. Zespół musi zachować dostęp umożliwiający przywrócenie działania, przetestować wymagane połączenia, sprawdzić skutek zmiany i zapisać sposób jej cofnięcia. Skopiowana reguła zapory nie uwzględni istniejącej polityki ani jej zależności.

Każdy przypadek oczekujący na poprawkę powinien mieć przypisaną osobę i termin kolejnego sprawdzenia komunikatów. Eskaluj decyzje wymagające przestoju, działania dostawcy lub czasowego przyjęcia pozostałego ryzyka. Nasz poradnik eskalowania poprawek bezpieczeństwa pokazuje, jak jasno zapisać taką decyzję.

Co trzeba zaktualizować w związku z CVE-2026-106378 w Chrome?

Zaktualizuj Chrome na macOS do bieżącej wspieranej wersji stabilnej i uruchom przeglądarkę ponownie. Rekord CVE Google wskazuje jako podatne wersje starsze niż 155.0.8059.39. Ta historyczna granica poprawki nie jest zaleceniem pozostania przy starym wydaniu przeglądarki.

Google uwzględnił tę poprawkę w wydaniu Chrome 155 z 6 października. Wpis PWN.AI z 30 października przedstawia późniejsze badanie dotyczące poprawki, która była już dostępna.

W badaniu PWN.AI kod działający już w procesie GPU Chrome mógł wysyłać syntetyczne naciśnięcia klawiszy przez WindowServer systemu macOS. Demonstracja otwierała Spotlight i uruchamiała Kalkulator poza piaskownicą GPU. Badacze wyraźnie zaczynają od możliwości wykonywania kodu natywnego w procesie pomocniczym GPU. Ich test pokazuje więc etap wyjścia z piaskownicy, a nie początkowe przejęcie przeglądarki.

Opis CVE Google wymaga wcześniejszego przejęcia procesu renderującego i przypisuje podatności poziom Medium w skali ważności Chromium. Zachowaj ten opis dostawcy obok konkretnego punktu wyjścia badania, czyli procesu GPU. Żaden z nich nie uzasadnia przedstawiania tego pojedynczego błędu jako kompletnego, uniwersalnego ataku przez samo odwiedzenie strony. Rekord CVE Google.

Poprawka Chromium dotyczy autoryzacji dziedziczonej w ramach TCC, systemu uprawnień chroniących prywatność w macOS. Jej opis wyjaśnia, że bezpośrednie uruchomienie pliku wykonywalnego Chromium z innego procesu może przekazać uprawnienia procesu nadrzędnego do Chromium i jego procesów potomnych. Potomny proces GPU nie powinien dziedziczyć takiej autoryzacji. Sposób uruchomienia i istniejące uprawnienia mają znaczenie dla opisanego zachowania.

Przypisz osobę odpowiedzialną za aktualizację przeglądarek i zapisz dowody:

W Chrome otwórz Pomoc → Google Chrome – informacje, poczekaj na zakończenie wspieranej aktualizacji i uruchom przeglądarkę ponownie, gdy pojawi się prośba. Potem jeszcze raz sprawdź wyświetlaną wersję. Procedurę opisuje instrukcja aktualizacji Chrome od Google. Sprawdzenie przeglądarki prowadź oddzielnie od aktualizacji jądra Linuksa: dotyczą innego oprogramowania i innych czynności potrzebnych do aktywacji.

Jakie dowody pozwalają zakończyć usuwanie tych podatności CVE?

Zakończ prace dla hosta, gdy można powiązać jego tożsamość, właściwą poprawkę, aktywne jądro i wynik weryfikacji. Wyjątki zapisuj osobno, żeby zakończone wdrożenie nie ukryło maszyny, która nadal czeka na działanie.

Dla zadania dotyczącego Chrome uzupełnij te same pola, wskazując Maca, instalację przeglądarki, komunikat i wersję po ponownym uruchomieniu. Restart jądra i ponowne uruchomienie przeglądarki zapisz przy właściwych im zadaniach.

Wystarczy krótki zapis, taki jak poniżej. To propozycja dokumentacji operacyjnej, a nie wymaganie dostawcy:

• Host i odpowiedzialność: stały identyfikator maszyny, usługa, środowisko i osoba prowadząca sprawę.
• Podatność danej konfiguracji: dystrybucja, rodzina jądra, pełna rewizja pakietu i URL komunikatu.
• Działanie: aktualizacja lub zatwierdzony środek tymczasowy wraz z czasem zakończenia.
• Aktywacja: wersja działająca po restarcie albo wyraźne potwierdzenie objęcia CVE wspieranym live patchem.
• Weryfikacja: kto i kiedy sprawdził dowody oraz czy wymagane usługi nadal działają prawidłowo.
• Pozostałe zadania: hosty z odroczoną aktualizacją, środki tymczasowe, obrazy maszyn zastępczych i termin kolejnego sprawdzenia.

Przy wielu serwerach wykaz ukończonych i otwartych zadań powinien opierać się na tym samym spisie hostów. Stwierdzenie „aktualizacja jądra została wdrożona” zostawia zbyt dużo miejsca na interpretację. Wskaż, które maszyny działają z poprawioną kompilacją, które mają ją zainstalowaną, ale nieaktywną, a które wciąż czekają.

Wyobraź sobie usługę działającą na trzech serwerach. Dwa zostały uruchomione ponownie z poprawionym jądrem. Trzeci ma zainstalowany pakiet, ale nie udało się wykonać restartu w planowanym terminie serwisowym. Nie zamykaj jego zadania: przypisz odpowiedzialną osobę i wyznacz nowy czas aktywacji.

Instalacja pakietu się powiodła, ale trzeci host nie spełnia jeszcze tego samego warunku zakończenia co pozostałe dwa.

Jeśli ekspozycję zgłosił badacz, potwierdź otrzymanie zgłoszenia i wyjaśnij, co zweryfikowano, bez ujawniania zbędnych szczegółów infrastruktury. Ten sposób komunikacji opisujemy w poradniku tworzenia programu ujawniania podatności (VDP).

Częste pytania o poprawki Linuksa i Chrome

Czy instalacja najnowszego pakietu jądra kończy naprawę?

Potwierdź, że pakiet zawiera zmianę dostawcy i że host z niego korzysta. Wykonaj wspieraną procedurę restartu lub live patchingu, a następnie udokumentuj aktywny stan.

Czy każdy serwer z Amazon Linux 2023 ma poprawkę?

Sama nazwa dystrybucji nie wystarcza. W zestawieniu z 30 października tracker Amazon wskazuje poprawki dla kernel6.12 i kernel6.18, ale domyślna linia kernel nadal na nie czeka. Dopasuj rodzinę pakietu na hoście do aktualnego komunikatu Amazon.

Czy pozornie stara wersja jądra dowodzi podatności?

Utrzymywana dystrybucja może przenieść poprawkę do starszego wydania. Porównaj pełną rewizję pakietu dostawcy z komunikatem, a potem potwierdź aktywację. Samo porównanie z wersjami projektu Linux nie wystarcza.

Czy ostrzeżenie oznacza, że ktoś włamał się na mój serwer?

Alert o podatności uzasadnia sprawdzenie ekspozycji i usunięcie błędu. Stwierdzenie włamania wymaga osobnych dowodów z twojego środowiska. W dokumentacji rozdziel aktualizację zabezpieczeń od dochodzenia dotyczącego incydentu.

Czy wyjście z piaskownicy Chrome dowodzi, że strona może przejąć każdego Maca?

Opublikowana demonstracja dotycząca GPU zakłada wcześniejszą możliwość wykonywania kodu natywnego, a opis CVE Google również wymaga wcześniejszego przejęcia procesu renderującego. Zaktualizuj podatne przeglądarki, ale zachowaj te warunki w opisie badania.

Zachowaj odpowiedzialność za zgłoszenie i historię weryfikacji w Kit

Do sprawnego przekazania sprawy wystarczą: przypisana osoba, właściwy komunikat, wykonane działanie i sprawdzone dowody. Zespół sam bada i aktualizuje hosty. Dokumentacja sprawy pozwala kolejnej osobie zrozumieć podjętą decyzję.

Obsługa zgłoszeń podatności w Kit pozwala przypisać zgłoszenie, zachować historię przypisań i statusów oraz odróżnić stan „Rozwiązane” od stanu „Poprawka zweryfikowana”. Uprawniona osoba może oznaczyć poprawkę rozwiązanego problemu jako zweryfikowaną i dodać opcjonalną notatkę. Notatka może odsyłać do dowodów z hostów. Sama zmiana statusu jest potwierdzeniem osoby weryfikującej, a nie automatycznym testem jądra.

W przypadku CVE-2026-98432 przejdź od aktualnej pozycji pakietu u dostawcy do potwierdzenia stanu działającego hosta. Przy CVE-2026-106378 sprawdź działającą wersję Chrome po ponownym uruchomieniu przeglądarki. Maszyny oczekujące na działanie powinny pozostać widoczne do spełnienia właściwego warunku zakończenia. Jeśli przy obsłudze zgłoszeń podatności potrzebujesz jasnej odpowiedzialności i wspólnej historii weryfikacji, możesz wypróbować Kit.