Node.js, Java i Python: najnowsze luki w zabezpieczeniach i przewodnik po ich naprawie

Źródła sprawdzone na dzień 23 października 2026 r. (UTC) Okres ochrony: 25 lipca – 23 października 2026 r., ze szczególnym uwzględnieniem nowych ogłoszeń i kolejnych poprawek od września do października. Audience: inżynierowie i osoby odpowiedzialne za bezpieczeństwo, które obsługują usługi Node.js, Java, Python, kontenery, budują rurociągi i środowiska programistyczne.

W tym artykule podsumowano najnowsze ważne zagrożenia bezpieczeństwa w środowiskach wykonawczych Node.js, Java i Python, bibliotekach standardowych oraz typowych strukturach i zależnościach serwerów, a także przedstawiono zakres wpływu, stałe wersje, tymczasowe środki łagodzące, wybór poprawek i metody weryfikacji.

Oceń wpływ wersji komponentów, włączonych funkcji i dostępnych punktów wejścia. Dane dotyczące luk w zabezpieczeniach pochodzą z oficjalnych poradników; daty odnoszą się do ujawnienia publicznego, chyba że wyraźnie wskazano wcześniejszą wersję poprawki. Nie wnioskujemy o niepotwierdzonych warunkach exploitów, wynikach CVSS ani eksploatacji w środowisku naturalnym. Porady dotyczące wdrożenia są określane jako wytyczne dotyczące wdrażania.

TL;DR: priorytety działań naprawczych

Zaktualizuj najpierw środowisko wykonawcze, które faktycznie hostuje usługę. Zaktualizuj odpowiednią gałąź Node.js do co najmniej 22.23.4 / 24.22.1 / 26.12.1. Usługi korzystające z Node 24 można zaktualizować do 24.22.1 w ramach tej samej wersji głównej lub nowszej wersji, która zawiera te same poprawki. S1 S2
UZaktualizuj oddzielnie zależności aplikacji Node. W przypadku Next.js użyj 15.5.28 / 16.4.1 jako podstawy aktualizacji; jeśli używasz React Server Components niezależnie, sprawdź faktycznie zainstalowany pakiet react-server-dom-*. Jedynie aktualizacja pliku binarnego Node nie obejmuje tych luk w zabezpieczeniach frameworka. S8 S9 S10 S11 S12
Java: obejmuje obie rundy aktualizacji. Zainstaluj kompilację dostawcy obejmującą zarówno awaryjną poprawkę zaufania certyfikatu CPU z 20 października, jak i CVE-2026-91403 z 21 października. Patrz sekcja 2.2 dla wersji pozapasmowych Oracle JDK 11-27; sprawdź inne dystrybucje pod kątem ich własnych pakietów bezpieczeństwa i pełnych numerów kompilacji. Zaktualizuj odpowiednią gałąź Tomcat do 9.0.123 / 10.1.61 / 11.0.27. S16 S17 S18 S20 S21 S22 S23
Python : zaktualizuj oddzielnie interpreter, pakiety aplikacji i pakiety certyfikatów. Zobacz sekcję 2.3 dla wartości wyjściowych tłumacza; certifi zaleca ≥ 2026.10.19 , pip ≥ 26.2.2 , podczas używania uv ≥ 0.13.4 . Należy sprawdzić każdy istniejący Venv. Dla wrap_bio() powiązane kody, poprawne i niepuste server_hostname trzeba też przekazać. S29 S30 S31 S33 S35 S36 S37
Jeśli natychmiastowa aktualizacja nie jest możliwa, zmniejsz narażenie w odpowiednich punktach wejścia. Nadaj priorytet zatrzymaniu niezaufanego dekodowania Brotli, przetwarzania obrazu/stronicowania/archiwizacji, którego to dotyczy, oraz izolowania problematycznych wpisów LDAP lub uwierzytelniania; weryfikowanie certyfikatów i nazw hostów TLS. Przychodzące WAF nie obsługuje ścieżek wychodzących, takich jak aplikacje pobierające złośliwe, skompresowane odpowiedzi. S3 S11 S25 S27 S30 S32
Odbuduj, zastąp stare procesy i weryfikuj poprzez rzeczywiste ścieżki usług. Zapisz plik blokady i podsumowanie obrazu, przebuduj aplikację i obraz, wprowadź zamienniki dla wszystkich pracowników/JVM/kontenerów; sprawdź rzeczywisty proces, drzewo zależności, magazyn zaufania i testy regresji biznesowej. Sama nowsza wersja wiersza polecenia nie gwarantuje, że naprawa została ukończona.
Jeśli LiteLLM 1.107.0 został zainstalowany lub uruchomiony, postępuj zgodnie z procedurami reagowania na incydenty. Projekt potwierdził kompromis w sprawie wydania 21 października. Izoluj dotknięte środowiska, badaj z czystego środowiska, odbuduj i rotuj ujawnione poświadczenia. Nie uruchamiaj Python/pip w podejrzanym środowisku, aby najpierw sprawdzić. Aby uzyskać szczegółowe informacje, zobacz sekcję 9. S41

1. Przegląd podatności i ocena ryzyka

1.1 Priorytetowo traktuj środki zaradcze w oparciu o rzeczywiste narażenie

Poniższe priorytety wdrożeniowe stanowią wytyczne dotyczące wdrażania. Etykiety ważności są dołączone do każdego dostawcy, w tym ocena Apache Important. CVSS 3.1 i 4.0 to różne systemy punktacji; nie klasyfikuj problemów według samego wyniku.

Ekosystem / warstwa	Kluczowe kwestie	Oficjalna ocena lub zweryfikowany wynik	Wdrożenie priorytetowe
Zależność natywna Node.js	CVE-2026-111497: Brotli jest zapisane poza zakresem i istnieje ryzyko RCE	Node：High	Dekoduj dane Brotli S1 S3 w treści żądania zewnętrznego lub odpowiedzi zewnętrznej
Node.js TLS / DNS	CVE-2026-105482, 105483, 106069: Analiza składniowa i weryfikacja tożsamości są niespójne	High	URL indeksowanie, proxy, Webhook, dynamiczny adres docelowy S1 S5 S6
Node.js HTTP/2	CVE-2026-56846, 56848: Wyczerpana pamięć i UAF	High	Node bezpośrednio obsługuje niezaufany ruch HTTP/2 S7
React / Next.js	RSC / `use cache` typed arrays RCE	Critical；CVSS 4.0 9.5	Serwer RSC, powiązane komponenty pamięci podręcznej i ścieżka danych S9 S10
Next.js Optymalizacja obrazu	CVE-2026-96889: SVG Przetwarzanie obrazu RCE	Critical；CVSS 4.0 9.5	Instancje na glibc Linux, które mogą obsługiwać niezaufane obrazy S11
Next.js Server Actions	Specjalnie spreparowane żądanie powoduje wyczerpanie CPU	High；CVSS 4.0 8.2	App Router i co najmniej jeden Server Action S12
Java TLS Zaufanie	CVE-2026-91403: Nadal ufaj pośrednikowi, którego dotyczy problem CA	CVSS 3.1 9.1	TLS/API Scenariusz S17 z wykorzystaniem łańcucha zaufania, którego dotyczy problem
Tomcat	Obejście uwierzytelnienia JNDIRealm, pomyłki w żądaniach krzyżowych HTTP/2, wyciek odpowiedzi AJP	Important	Odpowiadająca ścieżce Realm / Connector / async Servlet S21 S22 S23
Spring for GraphQL	CVE-2026-59285: Deserializacja stronicowania RCE	High	Jackson 2 + Connection Stronicowanie + ścieżka klas, którą można wykorzystać S25
Spring Security	CVE-2026-59270: Wbudowana LDAP ujawniona znana tożsamość zarządzania	Critical	Wbudowany LDAP jest włączony, a port nasłuchiwania jest dostępny dla atakującego S27
CPython `ssl`	CVE-2026-19445: Wyniki kontekstu przełączania SNI w UAF	Critical	Python sam kończy TLS i spełnia warunek cyklu życia kontekstu S29
CPython `ssl`	CVE-2026-19553: Pomiń weryfikację, jeśli brakuje nazwy hosta	High	`wrap_bio()` / Brak oczekiwanej nazwy hosta w powiązanym wywołaniu asyncio S30
CPython `tarfile`	CVE-2026-82049: Pominięcie kombinacji łącza twardego i łącza symbolicznego	High	Automatycznie wyodrębnij niezaufane archiwum tar S32
Django / GeoDjango	CVE-2026-15307: Plik zapisu zapytań przestrzennych, SSRF, pod warunkiem RCE	High	Zapytania przestrzenne lub powiązane interfejsy administracyjne akceptujące niezaufane dane wejściowe S38
Zależność certyfikatu Python	certifi: brak zaufania do certyfikatu powiązanego z emSign	Critical; GHSA, żaden nie jest znany CVE	TLS narzędzie do zarządzania klientami i pakietami S36 S37 nadal używa wadliwego CA bundle

Skróty: RCE oznacza zdalne wykonanie kodu, UAF oznacza użycie po zwolnieniu, a SSRF oznacza fałszowanie żądań po stronie serwera. Bezpośrednie uprawnienia RCE są zazwyczaj uprawnieniami procesu obsługującego aplikację i nie mogą być automatycznie równoważne z uprawnieniami roota.

Zalecana sekwencja: najpierw obsługuje RCE, który jest osiągalny zewnętrznie i spełnia warunki, obejście uwierzytelnienia, wyciek danych między użytkownikami i problemy z uwierzytelnianiem certyfikatu; jednocześnie zaplanuj aktualizacje dla publicznego punktu wejścia DoS. Nie ma potrzeby uruchamiania ładunków ataku w środowisku produkcyjnym, aby udowodnić przydatność do wykorzystania. Istnieją zależności, ścieżki kodu są osiągalne i spełnione są warunki ataku. To trzy kwestie, które należy sprawdzić osobno.

1.2 Trzy granice, które łatwo pomylić

Uaktualizuj środowisko wykonawcze i zależności oddzielnie. Aktualizacje zabezpieczeń dla Node, JDK, CPython nie naprawiają automatycznie samodzielnych instalacji Next.js, Spring, Django, certifi lub rozszerzenia natywne.
Próg zaradczy jest oddzielony od bieżącego punktu odniesienia wdrożeniowego. Nie ma gwarancji, że pierwsza łata dla luki w sierpniu obejmie nowe problemy od września do października; W sekcji 2 jako cel wdrożenia przyjęto zweryfikowane kolejne aktualizacje.
Odróżnij lukę od rzeczywistego naruszenia bezpieczeństwa łańcucha dostaw. W przypadku typowych luk poprawki eliminują przyszłe ścieżki ataków; po uruchomieniu złośliwych pakietów należy zbadać wpływ poświadczeń i trwałości. Oficjalnie potwierdzonym wydarzeniem jest LiteLLM Sekcji 9. S41

To, czy potwierdzono eksploatację na wolności, powinno opierać się na oficjalnych ujawnieniach. Sprzedawca nie wspomniał o działaniach związanych z wykorzystywaniem i nie może udowodnić, że nie doszło do ataku; środki zaradcze należy przeprowadzić w oparciu o rzeczywistą powierzchnię ataku.

2. Szybkie sprawdzenie poprawionej wersji i podstawy wdrożenia

Źródło: 2.1 Node.js、React、Next.js

komponent/gałąź	Zalecana wersja podstawowa	Instrukcje użytkowania
Node.js 22.x	22.23.4	Wydanie zabezpieczeń S1 S2 z 21 października
Node.js 24.x	24.22.1	Dotyczy gałęzi 24.x; 24.22.0 nie zawiera poprawki zabezpieczeń z 21 października S1 S2
Node.js 26.x	26.12.1	Wersja zabezpieczeń w tej samej partii S1 S2
Node.js 20 i wcześniejsze gałęzie wyższego szczebla	Przeprowadź migrację do obsługiwanej gałęzi	Node 20 nie akceptuje tej poprawki źródłowej; rozszerzone wsparcie dostawcy należy zweryfikować osobno S3
Next.js 15.x	15.5.28	Zaktualizowano 14 października S8
Next.js 16.x	16.4.1	To samo co powyżej S8
Samodzielny oddział RSC 19.0 / 19.1 / 19.2 / 19.3	19.0.9 / 19.1.10 / 19.2.9 / 19.3.1	Sprawdź osobno trzy pakiety `react-server-dom-*`; nie tylko spójrz na górną warstwę `react` S10
Next faktycznie załadował `sharp`	≥0.35.5	Oficjalne warunki tymczasowej naprawy luki SVG; nie zastępuje innych poprawek Next.js S11

Node oficjalnie zawiera listę gałęzi konserwacji, których dotyczy luka z października, ale nie podaje początkowo wprowadzonej wersji poprawki element po elemencie, więc dokładnej wersji początkowej każdej luki nie można określić na podstawie samego zakresu gałęzi konserwacji. Podczas wdrażania należy preferować użycie powyższej wersji tej samej gałęzi lub kolejnej wersji, która zawiera te same poprawki.

2.2 Java: październik CPU plus aktualizacja certyfikatu poza pasmem

Ta tabela dotyczy Oracle JDK. Druga kolumna obejmuje tylko CPU z 20 października; trzeci obejmuje wydanie poza zespołem z 21 października. Same wersje CPU nie obejmują wszystkich omówionych tutaj zagrożeń związanych z Java. S16 S17 S18

oddział	20 października CPU	Oracle został wydany poza zespołem 21 października
11	11.0.33	11.0.33.0.2
17	17.0.21	17.0.21.0.2
21	21.0.13	21.0.13.0.2
25	25.0.5	25.0.5.0.2
27	27.0.1	27.0.1.0.2
8	8u511	Tabela wydań publicznych nadal pokazuje 8u511; należy sprawdzić konkretną kompilację zabezpieczeń i naprawę łańcucha zaufania i nie można ich określić na podstawie samego krótkiego numeru wersji

**Java 8 należy sprawdzić pod kątem pełnych informacji o kompilacji:**Oracle Alert wymienia 8u511 jako wersję, której dotyczy problem, a lista wydań zawiera listę kolejnych aktualizacji o tej samej krótkiej nazwie. Statusu poprawki nie można rozróżnić na podstawie samego krótkiego numeru wersji „8u511”. Powinieneś potwierdzić konkretną kompilację zabezpieczeń i poprawki łańcucha zaufania. S17 S18

Temurin, Corretto, Zulu, Microsoft Build of OpenJDK, wersja wydania OpenJDK itp., sprawdź zgodnie z odpowiednimi ogłoszeniami i pełnymi numerami pakietów/kompilacji. Na przykład oficjalny zapis wydania Adoptium stwierdza, że odpowiednia kompilacja została przepakowana w celu dodania poprawki eMudhra; ta sama nazwa wersji źródłowej nie oznacza, że zawartość pakietu jest taka sama. Reguł sufiksu .0.2 dla Oracle nie można mechanicznie zastosować do innych wydawców. S20

Komponenty aplikacji Java	Zalecana wersja podstawowa	Uwagi
Tomcat 9 / 10.1 / 11	9.0.123 / 10.1.61 / 11.0.27	Sprawdź oddział po oddziale; Tomcat 10.0 zatrzymał konserwację S21 S22 S23
Spring for GraphQL 2.0.x	2.0.5（OSS）	Wsparcie komercyjne to także 2.0.4.1 S25
Spring Security 7.1 / 7.0	7.1.1 / 7.0.7（OSS）	Odpowiada minimalnej wersji poprawki ogłoszonej w sierpniu; przed wdrożeniem należy sprawdzić kolejny biuletyn bezpieczeństwa S27 S28
Spring Security 6.5 / 6.4 / 5.8 / 5.7	6.5.12 / 6.4.19 / 5.8.28 / 5.7.26	Ogłoszenie jest wymienione jako poprawka do komercyjnego wsparcia; migracja jest oceniana, gdy nie ma odpowiedniego wsparcia i nie można założyć, że Maven Central jest dostępny za darmo S27

Aktualizacje Spring powinny uwzględniać minimalną wersję projektu Spring Boot BOM, Java i linie kompatybilności. Nie zmuszaj bezpośrednio wszystkich modułów Spring do tego samego numeru tylko po to, aby uzyskać łatkę.

2.3 CPython, Django i zależności certyfikatów

Druga kolumna poniższej tabeli skupia się na ujawnionym we wrześniu numerze TLS; różnice w gałęziach dla tarfile pokazano w sekcji 5.3. W wydaniach z 21 października zaktualizowano także narzędzia do certyfikatów w pakiecie, więc ostatnia kolumna zawiera podstawy późniejszego wdrożenia. S29 S30 S33 S35

Oddział CPython	Minimalna wersja pakietu zabezpieczeń z września	Zalecana podstawa wdrożenia
3.10	3.10.22	Ostatnia wersja od producenta, EOL; zorganizuj migrację lub sprawdź obsługę rozszerzenia wersji S34
3.11	3.11.17	3.11.17 i aktualizuj pip/certifi w każdym środowisku indywidualnie
3.12	3.12.15	3.12.15 i aktualizuj pip/certifi w każdym środowisku indywidualnie
3.13	3.13.16	3.13.17
3.14	3.14.8	3.14.9
3.15	Ostateczna wersja 3.15.0 zawiera zarówno poprawki TLS, jak i S31 S47	3.15.1

Wersje zabezpieczeń nadrzędne 3.11 i 3.12 mogą być wydawane wyłącznie w kodzie źródłowym; korzystając z pakietu systemu operacyjnego, sprawdź zalecenia dostawcy dotyczące backportu i pełną wersję pakietu. Nie ma wymogu przymusowej wymiany systemu Python na samodzielnie skompilowaną wersję. S33 S34

niezależna zależność	Zalecana wersja podstawowa	Opis
Django 5.2 / 6.0 / 6.1	5.2.18 / 6.0.9 / 6.1.2	Uwzględnij kolejną korektę S38 S39 w dniu 6 października
certifi	≥2026.10.19	Początkowa poprawka GHSA to .18; PSF zaleca wersję .19 w celu zachowania zgodności dla nienaruszonych certyfikatów. S36 S37
pip	≥26.2.2	Wbudowana kopia certifi wymaga osobnej aktualizacji S35 S37
uv (jeśli jest używany)	≥0.13.4	Zaktualizuj S37 zgodnie z rzeczywistą metodą instalacji

Te wartości bazowe obejmują wymienione poprawki. Kolejny problem o średniej wadze w tar_filter został ujawniony 22 października. Na dzień 23 października 2026 r. oficjalna wersja serwisowa zawierająca tę poprawkę nie została jeszcze potwierdzona. dlatego też nie można uznać, że 3.13.17 / 3.14.9 / 3.15.1 obejmuje wszystkie problemy z plikami tar. Patrz rozdział 5.4. S40

2.4 Weryfikacja backportów dystrybucji

Zasady wdrożenia dotyczące Ubuntu, Debian, RHEL i innych pakietów oprogramowania:

Zapisz wersję systemu operacyjnego, źródło repozytorium, pełną wersję pakietu i numer biuletynu bezpieczeństwa dostawcy.
Potwierdź, że poradnik obejmuje konkretny CVE i identyfikuje stały pakiet dla odpowiedniej wersji dystrybucyjnej.
Porównaj pliki binarne/biblioteki załadowane przez aktualnie działający proces, a nie tylko skróconą wersję źródłową.
Jeśli nie ma dowodów na istnienie łatki dostawcy, pozostaw ją „do potwierdzenia” i nie traktuj tego jako jedynego wniosku, że numer wersji wygląda na stary lub nowy.

Istnieją różnice w wersjach pakietu apt/RPM i strategiach backportu w różnych dystrybucjach. Biuletyn bezpieczeństwa i pełna wersja pakietu każdej dystrybucji powinny mieć pierwszeństwo.

3. Ekosystem Node.js / JavaScript: Analiza przyczyn i środki zaradcze

3.1 CVE-2026-111497: Brotli natywny zapis dekodera poza zakresem

Ujawnienie: 2026-10-21; Oficjalna klasa Node: High. Wersje Node 22.x, 24.x, 26.x, których to dotyczy, wymagają zainstalowania sekcji poprawki 2.1. Node W ogłoszeniu nie podano liczbowego wyniku CVSS. S1

Problem występuje w natywnej logice dekodowania podczas obsługi zniekształconego skompresowanego strumienia Brotli, co może prowadzić do zapisów poza zakresem. Oficjalny opis Vercel potwierdza, że demonstracja badawcza obejmuje wycieki pamięci procesów i wykonanie poleceń. To, czy osoba atakująca może dotrzeć do dekodera, zależy od tego, czy aplikacja lub zależność faktycznie dekoduje dane, które kontroluje. S3

Obydwa kierunki należy sprawdzić jednocześnie:

inbound: Struktura lub oprogramowanie pośredniczące automatycznie dekompresuje treść żądania Brotli przesłaną przez użytkownika.
**outbound:**HTTP Klienci, programy pobierające obrazy itp. uzyskują dostęp do źródeł kontrolowanych przez atakującego i automatycznie dekompresują zwróconą zawartość.

Wyłączenie kompresji Brotli odpowiedzi wysyłanych do przeglądarek nie usuwa punktu wejścia dekodowania. Ochrona ruchu przychodzącego WAF nie obejmuje również pobierania i dekodowania odpowiedzi zewnętrznych aplikacji. S3

**Kierunek poprawki:**Node Przenieś poprawkę nadrzędną Brotli do natywnej zależności i uzupełnij sprawdzanie statusu nielegalnego dekodowania i propagację błędów. Utrzymując samodzielnie skompilowaną wersję, powinieneś używać oficjalnej wersji zabezpieczeń lub pełnej łatki z odpowiedniej gałęzi. Nie można po prostu zmienić instrukcji wersji pakietu JavaScript. S4

Tymczasowe sugestie dotyczące wdrożenia: zatrzymaj niepotrzebne niezaufane dekodowanie Brotli; sprawdź zachowanie automatycznej dekompresji oprogramowania pośredniego i klienta HTTP; jeśli firma musi zaakceptować ten format, dokończ przetwarzanie w środowisku z poprawkami tak szybko, jak to możliwe. Dostosowanie Accept-Encoding jest jedynie aktem negocjacji i nie powinno być samodzielnym dowodem na to, że złośliwa odpowiedź została zablokowana.

3.2 TLS / DNS trzy High: Obiekt weryfikacji jest niezgodny z rzeczywistym celem

Wszystkie trzy zostały ujawnione 21 października, a oficjalny próg aktualizacji został określony w sekcji 2.1. S1

Identyfikator	Problem potwierdzony	Dotknięte gałęzie
CVE-2026-105482	`dns.resolve` Obcięcie nazw zawierających NUL	22.x / 24.x / 26.x
CVE-2026-105483	IP w postaci numerycznej o pełnej szerokości powoduje pominięcie weryfikacji nazwy hosta certyfikatu	24.x / 26.x
CVE-2026-106069	Nazwa hosta, którą można luźno zinterpretować jako IP, powoduje ominięcie weryfikacji TLS	22.x / 24.x / 26.x

DNS Istota problemu polega na tym, że ciąg sprawdzany przez górną warstwę różni się od nazwy faktycznie analizowanej przez dolną warstwę. Oficjalna łatka odrzuca NUL przy wpisie analizy i dodaje pokrycie regresji. S6

TLS Dwa elementy dotyczą normalizacji nazw, spójności interpretacji IP i dopasowania certyfikatów. Poprawka, dzięki której niestandardowe dane wejściowe IP są odrzucane lub obsługiwane poprawnie, aby uniknąć pomylenia rzeczywistego punktu końcowego IP z tożsamością domeny certyfikatu. S5

Rzeczywiste sugestie dotyczące rozwiązywania problemów dla : dają pierwszeństwo sprawdzeniu kodu użytkownika odbierającego URL, dynamicznego celu proxy lub adresu Webhook; ujednolicona standaryzacja i zezwolenie na ocenę listy, odrzuca NUL/znaki sterujące, potwierdza, że legalne IPv4, IPv6 i międzynarodowe nazwy domen nadal działają. Możliwość dalszego kształtowania SSRF wymaga zastosowania dowodu powiązania, którego nie można bezpośrednio wywnioskować z nazwy CVE.

Nie używaj NODE_TLS_REJECT_UNAUTHORIZED=0 lub rejectUnauthorized: false do eliminacji błędów sumy kontrolnej po aktualizacji. Należy poprawić adres, certyfikat i konfigurację biznesową.

3.3 Lipiec HTTP/2 High – problemy z modelem ryzyka i uprawnieniami

Dochodzeniem nadal należy uwzględnić następujące kwestie ujawnione w lipcu. Podczas wdrażania zaleca się bezpośrednie użycie październikowej wersji bazowej zabezpieczeń w sekcji 2.1. S7

CVE	Przyczyny i skutki	Pierwsza poprawiona wersja
CVE-2026-56846	Zachowany blok HTTP/2 header nie jest prawidłowo uwzględniony w budżecie `maxSessionMemory` i może wyczerpać pamięć; Wpływ 22.x / 24.x	22.23.2 / 24.18.1
CVE-2026-56848	HTTP/2 ponownie wchodzi na ścieżkę wysyłania podczas zbierania pakietów, powodując powstanie sterty UAF; wpływ 22.x / 24.x / 26.x	22.23.2 / 24.18.1 / 26.5.1
CVE-2026-58043	`--permission` Dopasowanie granic prefiksu ścieżki jest zbyt szerokie i można uzyskać dostęp do plików spoza listy dozwolonych.	Takie same jak trzy linie konserwacji powyżej

Wszystkie trzy to oficjalnie High. Pierwsze dwie pozycje dają pierwszeństwo sprawdzeniu, czy HTTP/2 jest przetwarzane przez samo Node; trzeci element ma odpowiednie znaczenie tylko wtedy, gdy korzysta się z modelu uprawnień i opiera się na tej granicy. Nie wszystkie elementy modelu uprawnień można opisać jako sieciowe RCE, które nie wymagają uwierzytelniania. S7

Tymczasowe zakończenie HTTP/2 na oddzielnym, zaktualizowanym serwerze proxy i ograniczenie źródeł zaplecza to opcja wdrożenia mająca na celu zmniejszenie narażenia; przydziały zasobów mogą jedynie kontrolować konsekwencje wyczerpania zasobów i nie mogą zawierać poprawki UAF.

3.4 Październik React / Next.js: dwie pozycje RCE i jedna pozycja DoS

A. Funkcje RCE w RSC / `use cache` zwracające tablice z określonym typem

Data publikacji: 2026-10-14; Critical, CVSS 4.0 9.5. Oficjalne identyfikatory doradcze:

React：GHSA-xqc2-xf4c-x3h3。
Next.js：GHSA-673q-mjm6-r5xr。S9 S10

Problem nadrzędny React obejmuje wiele tablic z określonym typem połączonych z wartościami kontrolowanymi przez osobę atakującą w odpowiedzi RSC. Trzy wersje pakietu react-server-dom-*, których dotyczy problem, to 19.0.0 — 19.0.8, 19.1.0 — 19.1.9, 19.2.0 — 19.2.8, 19.3.0; patrz rozdział Sekcja 2.1. Czysta przeglądarka React lub aplikacje, które w ogóle nie korzystają ze frameworków/wtyczek obsługujących RSC, nie wchodzą w zakres tego punktu. S10

Next.js dalsze listy ogłoszeń 16.0.0 — 16.4.0, poprawione w 16.4.1; scenariusz to funkcje App Router, Cache Components i use cache, które zwracają tablice z wieloma typami. Nie ma oficjalnego, niezawodnego, ogólnego obejścia, a użytkownicy wersji, których to dotyczy, są zobowiązani do terminowej aktualizacji. Niewłaściwe jest poleganie wyłącznie na ręcznym wyszukiwaniu hasła „wydaje się, że ta funkcja nie istnieje” w celu zakończenia przetwarzania. S9

Źródło: B. SVG Image Optimization RCE

CVE-2026-96889/GHSA-2464-fhr4-w9xw, 2026-10-14, Critical, CVSS 4.0 9.5. Problem występuje w natywnej bibliotece nadrzędnej używanej do optymalizacji obrazu. Urzędnicy wskazali, że ryzyko RCE istnieje w scenariuszu glibc Linux. S11

Oficjalne pola wersji to:

>=10.0.0 <=15.5.27；
>16.0.0 <=16.4.0。

Urzędnik stosuje ścisłą dolną granicę >16.0.0 dla gałęzi 16.x, ale to określenie zakresu nie wystarczy, aby udowodnić, że 16.0.0 jest bezpieczny. Rzeczywisty cel aktualizacji to jednakowo 15.5.28 / 16.4.1. S11

Oficjalnym rozwiązaniem tymczasowym jest zapewnienie, że Next faktycznie ładuje ostre ≥0.35.5. Pliki blokady, zagnieżdżone zależności i obrazy wdrożeniowe mogą nadal zawierać stare instancje, więc samo dodanie nowej wersji zależności sharp na najwyższym poziomie nie wystarczy, należy sprawdzić i odbudować ostateczne drzewo zależności. S11

C. Server Actions CPU wyczerpany

**GHSA-p3m5-59mp-jv5r, 2026-10-14, High, CVSS 4.0 8.2.**Next wpływa na 13.0.0—15.5.27, 16.0.0 — 16.4.0, poprawki 15.5.28 /16.4.1. Warunki to App Router i co najmniej jeden Server Action; złośliwe żądania mogą zająć CPU przez długi czas, blokując kolejne żądania w tym samym procesie. Nie ma to wpływu na aplikacje z Pages Router lub bez Server Actions. S12

Nie ma oficjalnego rozwiązania, które mogłoby zastąpić aktualizację. Limity szybkości, limity współbieżności i przydziały zasobów mogą zmniejszyć szkody, ale nie mogą być wykorzystywane jako wniosek do weryfikacji poprawek.

3.5 Wcześniejsze Next.js w tym samym oknie Poważny problem

Poniższe elementy mają na celu uniknięcie brakujących wdrożeń, które nadal utknęły w wersjach sprzed sierpnia i września; nie zaleca się teraz po prostu przechodzenia do starych progów poprawek podanych w tabeli.

Data	Identyfikator / scenariusz	Pierwsza poprawka; bieżąca akcja
2026-08-25	GHSA-2xp9-vwfh-vxw4: AVIF natywna biblioteka optymalizacji obrazu RCE, Critical	15.5.24 / 16.3.3; teraz 15.5.28 / 16.4.1 S13
2026-08-25	CVE-2026-75604: RCE, Critical, gdy Pages Router i App Router są używane jednocześnie na Windows, a Cache Components nie jest włączone; wersje `>=13.4.0 <15.5.24`, `>=16.0.0 <16.3.3`	15.5.24 / 16.3.3; Ten konkretny problem Windows nie dotyczy systemu Linux/macOS S14
2026-09-22	GHSA-vcvr-r3jv-pc5j: ścieżka generowania obrazu Node w procesach `next/og` niezaufanych SVG, Critical; 16.2.0 — 16.3.5	16.3.6; implementacja Edge wykracza poza zakres tego problemu, a 15.x nie jest gałęzią, której dotyczy ten RCE S15

4. Ekosystem Java: Zaufanie środowiska uruchomieniowego, kontenery i frameworki są obsługiwane oddzielnie

4.1 JDK: Zwykłe CPU i CVE-2026-91403 to aktualizacje dwupoziomowe

Matryca ryzyka Java SE dla Oracle CPU z 20 października zawiera listę nowych poprawek bezpieczeństwa 55, z których 49 oznaczono jako możliwe do wykorzystania w sieci bez uwierzytelniania. Nie oznacza to, że istnieje 55 Critical, ani nie oznacza to, że istnieje 49 bezpośrednio możliwych do wykorzystania ścieżek RCE dla każdej usługi sieciowej Java; należy to rozumieć w połączeniu z komponentami, interfejsami API, interakcjami użytkownika i warunkami wdrożenia w macierzy. S16

CVE-2026-91403 (CVSS 3.1 9.1) następnego dnia dotyczy innego rodzaju ryzyka: zestawu pośrednich CA związanych ze zdarzeniem eMudhra, które nie jest już zaufane. Wpływa na uwierzytelnianie równorzędne TLS oraz poufność/integralność komunikacji i nie można go opisać jako luki w zabezpieczeniach JVM powodującej uszkodzenie pamięci. S17

W poradniku Oracle wymieniono wersję wydaną 20 października jako dotkniętą problemem, dlatego też należy zainstalować aktualizację pozapasmową z 21 października. Informacje o konkretnej wersji można znaleźć w sekcji 2.2. GraalVM ma również odpowiednie produkty, których dotyczy problem, a poprawiona wersja powinna podlegać ekskluzywnemu biuletynowi bezpieczeństwa. S17 S18

Tymczasowe środki oficjalne: Najpierw wykonaj kopię zapasową, a następnie usuń określony certyfikat główny z każdego faktycznie używanego magazynu zaufanych certyfikatów:

emSign ECC Root CA - G3, alias w Oracle emsigneccrootcag3 [jdk].
AAA Certificate Services, alias w Oracle comodoaaaca [jdk]. S19

JDK 11 i nowsze, oficjalny przykład to:

keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

Użyj narzędzia keytool z docelowego JDK dla tych poleceń i potwierdź, że działają one w rzeczywistym magazynie zaufanych certyfikatów aplikacji. Java 8 wykorzystuje ścieżkę odpowiadającą jre/lib/security/cacerts; dostosowywanie magazynu zaufanych certyfikatów należy traktować osobno, a inni wydawcy mogą mieć różne aliasy. Usunięcie certyfikatu głównego rozszerzy zakres odrzuceń i umożliwi testowanie regresyjne legalnych łańcuchów certyfikatów usług. S19

Urzędnik udostępnia również opcję włączenia sprawdzania unieważnień, ale efekt zależy od faktycznej implementacji TLS, osiągalności usługi unieważnień i strategii awarii. W przypadku wdrożeń ogólnych priorytetem jest instalacja pełnych aktualizacji dostawcy, aby uniknąć traktowania dwóch przełączników JVM jako dowodu, że wszystkie biblioteki TLS zostały naprawione.

4.2 Tomcat: Pominięcie uwierzytelniania i izolacja żądań wielu użytkowników

Następujące trzy pozycje zostały opublikowane w 2026-10-20; wpis wersji naprawionej jest datowany na 12 października. Oficjalna klasa Apache to Important. S21 S22 S23

CVE	Potwierdzone wersje, których dotyczy problem	Niezbędne scenariusze/rezultaty
CVE-2026-101296	9.0.0.M1—9.0.122；10.1.0-M1—10.1.60；11.0.0-M1—11.0.26	JNDIRealm Konfiguruje mechanizm uwierzytelniania SASL inny niż GSSAPI, brak weryfikacji danych uwierzytelniających i mogą również zostać przesłane nieprawidłowe hasła
CVE-2026-101356	9.0.118—9.0.122；10.1.55—10.1.60；11.0.22—11.0.26	Obsługa błędów asynchronicznego serwletu HTTP/2 nieprawidłowo przetwarza/ponownie wykorzystuje obiekty, powodując mieszanie żądań lub odpowiedzi między użytkownikami
CVE-2026-103119	Potwierdź tylko 11.0.0-M25 — 11.0.26	Duże, nieblokujące zapisy AJP mogą powodować niedoczytanie bufora, ujawniając dane z poprzednich odpowiedzi w późniejszych żądaniach.

Odpowiednia poprawka to 9.0.123 / 10.1.61 / 11.0.27; Zgodnie z ogłoszeniem AJP jest wymieniony wyłącznie jako Tomcat 11 i nie można go rozszerzyć na trzy gałęzie z tym samym problemem. S21 S22 S23

Łatka JNDIRealm naprawia lukę weryfikacyjną w rzeczywistym procesie uwierzytelniania, w przypadku której zamiast weryfikacji nie można zastosować „interfejsu logowania aplikacji wyglądającego normalnie”. Należy sprawdzić mechanizmy SASL pod kątem faktycznej konfiguracji usługi, a testy pod kątem nieprawidłowych haseł muszą zakończyć się niepowodzeniem. S24

Tymczasowe sugestie dotyczące wdrożenia: izoluje ścieżkę uwierzytelniania, której dotyczy problem; zawiesić przetwarzanie HTTP/2 Tomcat, jeśli pozwala na to biznes; zamknij bezużyteczny AJP. Samo ograniczenie bezpośredniego dostępu do portu AJP nie może dowodzić, że nie będzie to miało wpływu na ruch przychodzący przez legalny front proxy. Po oficjalnej aktualizacji należy przetestować asynchroniczne, równoczesne żądania od dwóch niezależnych użytkowników, aby potwierdzić, że nie ma wzajemnego oddziaływania między tożsamościami i odpowiedziami.

Źródło: 4.3 Spring for GraphQL：CVE-2026-59285

Data publikacji: 2026-08-20; High. problem dotyczy 2.0.0 — 2.0.4, naprawiony 2.0.5 (OSS) lub 2.0.4.1 (wsparcie komercyjne). S25

Jest to niebezpieczne ryzyko deserializacji w zapytaniach stronicowania. Oficjalnym wymogiem jest jednoczesne spełnienie następujących warunków:

Użyj Spring for GraphQL.
Deserializuj JSON przy użyciu Jacksona 2.x.
Udostępnij pole stronicowania połączenia ze światem zewnętrznym.
Ścieżka klas zawiera określone klasy, które mogą wykonywać nieoczekiwaną logikę podczas tworzenia instancji lub deserializacji.

Złośliwe żądanie GraphQL może spowodować RCE, gdy zostaną spełnione warunki. Nie można tego sprowadzić do stwierdzenia, że „można wykorzystać wszystkie programy Java korzystające z Jacksona”. S25

Dlaczego 2.0.4 jest niewystarczający: W czerwcu CVE-2026-41699 podał podstawowe poprawki, takie jak 2.0.4, a w sierpniu ogłoszenie wyraźnie włączyło 2.0.4 w nowy zakres wpływu. W związku z tym należy zaktualizować zapis naprawy zgodnie z kolejnymi ogłoszeniami i nie można zastosować minimalnej wersji starego CVE. S26

Gdy aktualizacja jest tymczasowo niedostępna, pola stronicowania, których dotyczy problem, dostępne dla niezaufanych osób wywołujących, mogą zostać zawieszone; zawężenie typów i ścieżek klas, które można deserializować, jest miarą dogłębną. Regresje powinny obejmować legalne kursory, wyniki podzielone na strony i odrzucenia danych wejściowych wyjątków, a także sprawdzać rzeczywiste wersje komponentów w ostatecznym pliku JAR aplikacji.

4.4 Spring Security: CVE-2026-59270 i powiązane zagrożenia związane z uwierzytelnianiem

CVE-2026-59270, 2026-08-20, Critical. wbudowany UnboundIdContainer domyślnie rejestruje znane poświadczenia administratora i nasłuchuje na wszystkich interfejsach sieciowych. Gdy komponent jest włączony, a port jest dostępny, osoba atakująca może odczytać lub zmodyfikować dane katalogu; projekty, które zazwyczaj wprowadzają Spring Security, nie będą automatycznie ujawniać LDAP. S27

Dotknięty obszar:

oddział	dotknięty	Pierwszy kanał naprawy/pozyskania
7.1	7.1.0	7.1.1 OSS; również komercyjny 7.1.0.1
7.0	7.0.0—7.0.6	7.0.7 OSS; również komercyjny 7.0.6.1
6.5 / 6.4	6.5.0—6.5.11；6.4.0—6.4.18	6.5.12/6.4.19, komercyjny
5.8 / 5.7	5.8.0—5.8.27；5.7.0—5.7.25	5.8.28/5.7.26, komercyjny

Źródło: S27. Rozwiązywanie problemów z automatyczną konfiguracją spring.ldap.embedded.* i kodem bezpośredniej instancji; zamknij komponent, gdy nie jest on potrzebny do produkcji i sprawdź rzeczywisty adres odsłuchu. Kiedy firma naprawdę tego potrzebuje, najpierw ogranicz źródła połączeń, a następnie dokończ aktualizację komponentu.

**Powiązany problem z uwierzytelnianiem: CVE-2026-47841 (High).**WebAuthn Uwierzytelnianie użytkownika jest ustawione na REQUIRED, a po serializacji sesji HTTP przez pamięć rozproszoną nieprawidłowe porównanie tożsamości obiektów może unieważnić wymagania uwierzytelnienia. Atak wymaga również posiadania przez osobę atakującą urządzenia uwierzytelniającego użytkownika, a nie dowolnego zdalnego logowania bez urządzenia. W przypadku odpowiednich wersji 7.1, 7.0, 6.5 i 6.4, których dotyczy problem, baza poprawek jest zgodna z tymi gałęziami w powyższej tabeli; weryfikacja powinna obejmować sesje między węzłami i nadal wymagać weryfikacji PIN/biometrycznej. S28

5. Ekosystem Python: interpreter, biblioteka standardowa, framework i certyfikaty

5.1 CVE-2026-19445: SSLContext UAF w wywołaniu zwrotnym SNI

Data publikacji: 2026-09-30; PSF Poziom: Critical. W serwerze Python TLS, sni_callback przełącza połączenie na inny SSLContext, a gdy oryginalny kontekst nie ma innych zachowanych odniesień, nieuwierzytelniony Klient TLS może zawiesić usługę lub wywołać wskaźnik w zwolnionym obiekcie. S29

Sednem jest to, że obiekt Python jest niezgodny z podstawowym cyklem życia wywołania zwrotnego TLS. Oryginalny kontekst został zwolniony, a podstawowa warstwa może nadal utrzymywać stan wymagany do wywołania zwrotnego; Aby naprawić cykl życia odniesienia, należy użyć natywnej łatki interpretera. S47

Scope: Python kod, który działa tylko jako klient TLS, nie jest objęty tą pozycją; normalny tryb działania gniazda nasłuchowego utrzymującego przez dłuższy czas oryginalny kontekst nie wpada w specyficzną ścieżkę awarii opisaną w ogłoszeniu. Po tym, jak Nginx zakończy TLS, przekazuje jedynie lokalny HTTP Python, a Python bezpośrednio obsługuje samodzielnie SNI, co stanowi inną powierzchnię ataku. S29

Odpowiada naprawionej wersji 3.10—3.14, patrz rozdział 2.3.. Oficjalna wersja 3.15 została naprawiona i można faktycznie wybrać 3.15.1. Jedynie aktualizacja zależności pip nie może zastąpić implementacji _ssl interpretera. S33 S35 S47

Oficjalne tymczasowe środki zaradcze: zawiera silne odniesienia do wszystkich SSLContext, które ustawiły wywołanie zwrotne SNI do końca cyklu życia serwera. Musi to obejmować rzeczywiste ścieżki dynamicznego tworzenia i przełączania; niestandardowa kompilacja OpenSSL 1.1.1 powinna również sprawdzić warunki renegocjacji w połączeniu z oficjalnym zapisem problemu i dać pierwszeństwo dokończeniu aktualizacji. S29 S47

5.2 CVE-2026-19553: Flaga nazwy hosta jest włączona, ale podczas wywoływania brakuje nazwy hosta

Data publikacji: 2026-09-30; High. KiedySSLContext.check_hostname=True, jeśli wrap_bio() nie zostanie przekazane w server_hostname, oryginalna implementacja może po cichu pominąć weryfikację nazwy hosta. Pomyślna weryfikacja łańcucha certyfikatów nie oznacza, że docelowa nazwa domeny również została dopasowana. S30

Naprawa wymaga obu etapów:

Zainstaluj wersję zabezpieczeń interpretera wymienioną w sekcji 2.3.
Sprawdź ścieżki wrap_bio(), powiązane ścieżki asyncio.create_connection() / loop.start_tls(), jawnie podaj oczekiwaną i niepustą nazwę hosta i włącz weryfikację certyfikatu. S30

**Różnice w kompatybilności, których nie można pominąć:**3.10, 3.11, 3.12 służą do zapewnienia kompatybilności, w niektórych przypadkach, gdy brakuje nazwy hosta, wydawany jest tylko DeprecationWarning; 3.13 i później podnieś ValueError. Backport 3.12 również wyraźnie odróżnia None od pustych ciągów: dodano nowe ostrzeżenie dla None, a dla pustych ciągów nadal zgłaszany jest błąd. Dlatego też użytkownicy o niższych oddziałach nie mogą zakładać, że pierwotnie brakująca weryfikacja nazwy domeny została automatycznie przywrócona po prostu poprzez aktualizację. S31 S33

W środowisku testowym użyj certyfikatu zaufanego łańcucha z niezgodną nazwą hosta i potwierdź, że rzeczywisty klient aplikacji TLS go odrzuca. Samo odczytanie wartości logicznej check_hostname nie oznacza całkowitej akceptacji.

5.3 CVE-2026-82049: Pominięcie kombinacji łączy w filtrze pliku tar

Data publikacji: 2026-09-14; High. W CPython 3.13 i wcześniejszych pokrewnych implementacjach, kombinacja dowiązań twardych i dowiązań symbolicznych w niezaufanym pliku tar może ominąć filtr ekstrakcji data / tar, odsłaniając zawartość plików poza katalogiem rozpakowywania w drzewie rozpakowywania, lub modyfikowanie swoich uprawnień i czasów modyfikacji. S32

Potwierdzone skutki tej luki obejmują ujawnienie zawartości plików i modyfikację metadanych; same te wpływy nie są wystarczające, aby wykazać arbitralne nadpisanie zawartości pliku zewnętrznego lub bezwarunkową implementację RCE.

Odpowiednie linie bazowe poprawek 3.10 — 3.13 można znaleźć w sekcji 2.3.. Python 3.14 został zwolniony z tego konkretnego problemu ze względu na zmiany w zachowaniu os.link() od czasu 3.14.0b1, zatem zakres powyższej gałęzi 3.10 — 3.13, której dotyczy problem, nie ma zastosowania. S33

Środki tymczasowe i szczegółowe: zawiesza automatyczne wyodrębnianie niezaufanych archiwów; korzystaj z izolowanych procesów roboczych o niskich uprawnieniach i nowych ekskluzywnych katalogów, gdy sprawy muszą być przetwarzane, odmawiaj dowiązań symbolicznych, dowiązań twardych i wpisów urządzeń przez firmę oraz ograniczaj liczbę plików i zasobów dekompresyjnych. Są to zalecenia dotyczące wdrożenia.

filter="data" jest bardziej odpowiedni dla ogólnych niezaufanych archiwów niż strategia pełnego zaufania, ale sam filtr w starej wersji również ma tę lukę i samo dodanie tego parametru nie może zastąpić aktualizacji. Filtr nie jest także pełną piaskownicą systemu plików. S32 S45

5.4 Ryzyko dodatkowe: CVE-2026-114583 (Medium) i status wydania poprawki

PSF ujawnił w 2026-10-22, że przetwarzanie przez tarfile.tar_filter określonych nazw łączy może zostać ominięte, umożliwiając kolejnym członkom zapisywanie poza katalogiem rozpakowywania, z poziomem Medium. Oficjalna poprawka PR została połączona tego dnia; na dzień 23 października 2026 r. nie potwierdzono żadnej oficjalnej wersji konserwacyjnej zawierającej to zatwierdzenie. S40

Dlatego:

Pozycja ta jest wymieniona osobno jako Medium.
Nie można uznać, że wersje interpretera wydane 21 października zawierają tę poprawkę.
Proces, który nadal używa filter="tar" do obsługi niezaufanych archiwów, powinien śledzić backport wersji; odizolować lub zawiesić tę ścieżkę przetwarzania na krótki okres czasu. Przechodząc na data i odrzucając linki, trzeba także potwierdzić, że spełnia on wymagania biznesowe, a zmiany filtra nie można określić mianem bezwarunkowej piaskownicy.

5.5 GeoDjango: CVE-2026-15307 i kolejne poprawki w październiku

2026-08-04, Django oficjalne High. zapytanie przestrzenne pośrednio przekazuje określone ciągi znaków/słowniki do GDALRaster, a sterownik może zapisywać pliki lub inicjować żądania sieciowe; RCE może zostać utworzony, gdy istnieją określone ścieżki i późniejsze warunki wykonania. Personel posiadający uprawnienia do przeglądania modelu pola przestrzennego może również uzyskać dostęp do tej ścieżki poprzez listę zmian administratora. S38

Początkowa poprawka to 5.2.17 / 6.0.8, która ogranicza typy danych wejściowych akceptowane przez wyszukiwania przestrzenne. Ta zmiana może mieć wpływ na pierwotną działalność polegającą na używaniu ciągów znaków/słownika do wyrażania rastrów; zwykłe opakowanie niezaufanych danych wejściowych do GDALRaster nie oznacza ich weryfikacji. S38

6 października naprawiono CVE-2026-87890 (Umiarkowany): VRT wyrażony w bajtach może odwoływać się do zasobów zewnętrznych i nadal wyzwala żądania sieciowe; tego samego dnia wzmocniono również zabezpieczenie geometrii zagnieżdżonej DoS CVE-2026-15830. Tych dwóch ostatnich nie można zaktualizować w celu opisania nowego RCE wysokiego ryzyka, ale wskazują, że podstawą wdrożenia powinna być 5.2.18 / 6.0.9 / 6.1.2. S39

Implementacja sprawdza dwa punkty wejścia API i interfejsu administracyjnego, ogranicza niezaufane wyszukiwanie przestrzenne, uprawnienia do zapisu plików i dostęp wychodzący; po aktualizacji przetestuj regresję prawidłowych zapytań przestrzennych i odrzuć zabronione dane wejściowe. Zwykłe aplikacje Django, które nie korzystają z GeoDjango, nie powinny bezpośrednio stosować tego wniosku RCE.

5.6 certifi / pip: Certyfikat zaufania musi obejmować każdą kopię

GHSA-6q48-6c7w-9gw2, 2026-10-20, Critical, znany CVE nie wymieniony. To jest aktualizacja dotycząca braku zaufania do certyfikatu spowodowana incydentem pośrednim eMudhra CA. Nie można tego podsumować jako mechanizmu kryptograficznego HTTPS lub tego, że wszystkie certyfikaty główne zostały złamane. S36

W poradniku certifi pierwotnie wymieniono 2026.10.18 jako poprawkę; PSF później wyraźnie zalecił 2026.10.19, aby zachować zgodność z nienaruszonymi certyfikatami głównymi. Operacyjna linia bazowa to 0,19. S36 S37

Należy rozróżnić:

Zaufaj lokalizacji materiałów	Dlaczego musisz sprawdzić osobno
Pakiet systemu operacyjnego CA	Materiał zaufania systemowego dla obrazu lub hosta
certifi w wenw	CA bundle faktycznie używany przez aplikacje lub żądania itp.
pip wbudowany certifi	Jest inną kopią niż instalowany zewnętrznie certifi
uv / Inne narzędzia do pakowania	Śledź własne aktualizacje narzędzia i zaufane źródła
Dostosowane pliki CA, spakowane migawki	Może nadal zastępować domyślne zaufane źródła systemów lub pakietów

Powyższa lista kontrolna opiera się na różnych lokalizacjach pakowania. PSF wymaga aktualizacji powiązanych narzędzi, istniejących środowisk wirtualnych i przebudowania obrazu; jedynie aktualizacja hosta CA lub ponowna instalacja interpretera nie może udowodnić, że wszystkie kopie zostały odświeżone. S35 S37

Podczas aktualizacji ze starego bezpiecznego paska startowego pip, PSF udostępnia polecenia dla fixed Wheel i SHA-256, patrz dodatek S37. Nie wyłączaj weryfikacji TLS ani nie dodawaj --trusted-host, aby ominąć problemy z certyfikatami.

6. Formalny proces naprawczy

Poniższe polecenia dotyczą potwierdzonych zaufanych środowisk. Podczas wykonywania należy połączyć istniejący menedżer pakietów, plik blokady i proces wdrażania projektu, aby uniknąć mieszania npm/pnpm/yarn lub pip/uv/Poetry w celu wygenerowania sprzecznych plików blokady.

Zajmij się najpierw wyjątkiem: Jeśli podejrzewasz, że w środowisku uruchomiono zaatakowany pakiet z sekcji 9, najpierw go wyizoluj i sprawdź dysk, plik blokady i zapis obrazu z czystego środowiska; nie uruchamiaj najpierw następującej komendy Python/pip. S41

6.1 Utwórz księgę, która może odpowiadać rzeczywistemu ruchowi

Każda usługa rejestruje co najmniej:

Zewnętrzny punkt wejścia, zwrotny serwer proxy, ścieżka bezpośredniego połączenia z witryną źródłową oraz kolejka/zaplanowane zadania w tle.
Rzeczywiste polecenie uruchamiania, konto bieżące, ścieżka binarna, tożsamość procesu lub kontenera.
Pełna wersja środowiska wykonawczego, wydawca/repozytorium, pełna wersja pakietu lub podsumowanie obrazu.
Zależności strukturalne i przechodnie, pliki blokad, biblioteki natywne i ścieżki magazynu zaufanych certyfikatów.
Odpowiednio do tego, czy istnieje luka w zabezpieczeniach, cel poprawki, zakres ponownego uruchomienia, osoba odpowiedzialna i wynik weryfikacji.

Maszyny programistyczne, moduły CI, kontenery kompilacji i zadania w tle również należy sprawdzić pod kątem ich ścieżek do niezaufanej zawartości; nie aktualizuj tylko publicznego kontenera internetowego.

6.2 Node.js: Najpierw określ środowisko wykonawcze, a następnie zaktualizuj zależności aplikacji

Sprawdź rzeczywiste środowisko usług:

node -p 'JSON.stringify({execPath:process.execPath,node:process.version,openssl:process.versions.openssl,brotli:process.versions.brotli},null,2)'
npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack sharp --all
npm audit --omit=dev

node -p należy wykonać przy użyciu rzeczywistego pliku wykonywalnego usługi lub w rzeczywistym kontenerze; sprawdza nowo uruchomione procesy i sam w sobie nie udowadnia, że stary pracownik został zastąpiony. Node może dodać łatkę do wbudowanego Brotli, zachowując oryginalny ciąg wersji biblioteki. Dlatego nie należy polegać wyłącznie na process.versions.brotli w celu ustalenia, czy został naprawiony. Powinieneś połączyć go z wersją zabezpieczeń Node lub dowodem backportu dostawcy. S2 S4

npm ls służy do przeglądania aktualnego drzewa zależności; brakujące pakiety lub konflikty równorzędne mogą również generować niezerowe kody wyjścia, dlatego powinieneś przeczytać konkretne dane wyjściowe. npm audit służy jako pomoc w sprawdzaniu zależności i nie może zastąpić sprawdzania bibliotek binarnych i natywnych Node.

Użyj mise do zarządzania środowiskiem Node 24, które można aktualizować w następujący sposób:

mise use -g [email protected]
mise exec [email protected] -- node -p 'process.version + " " + process.execPath'

mise use -g konfiguruje wersję globalną; lokalną konfigurację projektu nadal należy sprawdzić osobno. Jeśli usługa naprawiła starą ścieżkę bezwzględną, podstawowy obraz kontenera lub środowisko innego konta, należy zaktualizować odpowiednią konfigurację i ponownie uruchomić usługę. Samo polecenie nie zastępuje starego działającego procesu. S43

W projekcie Next wykonaj odpowiednie polecenie zgodnie z wybraną gałęzią. Dla Next 15:

# Next 15 分支
npm install --save-exact [email protected]

Dla Next 16:

# Next 16 分支
npm install --save-exact [email protected]

Sprawdź zależności kompatybilne z React/RSC, zablokuj pliki i ostateczną instancję Sharp, a następnie zbuduj zgodnie z procesem projektu. Użyj zaktualizowanego pliku blokady w CI, aby zapewnić powtarzalną instalację, i sprawdź wersję w działającym obrazie po skompilowaniu. Nie używaj niekontrolowanej automatycznej naprawy w głównych wersjach jako domyślnego rozwiązania w tej sytuacji awaryjnej.

6.3 Java: Sprawdź wydawcę, rzeczywisty JVM i komponenty wbudowane

Wstępny spis:

java -XshowSettings:properties -version

java.home, java.runtime.version i wydawca w wynikach powinny być zgodne z JVM faktycznie używanym przez usługę. W przypadku JVM z uprawnieniami do dołączania, jcmd z JDK można użyć do sprawdzenia procesu docelowego, a nie tylko powłoki logowania.

Sprawdź zależności w zaufanych projektach i wybierz na podstawie rzeczywistych narzędzi do kompilacji:

./mvnw dependency:tree '-Dincludes=org.apache.tomcat.embed:*,org.springframework.security:*,org.springframework.graphql:*'

./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-security-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-graphql --configuration runtimeClasspath

Te polecenia kompilacji mogą uruchamiać wtyczki i rozwiązywać zależności online i działać tylko w zaufanych projektach. Sprawdź końcowy plik JAR/WAR lub rzeczywisty plik JAR na obrazie i nie zastępuj deklaracji pliku kompilacji ostatecznym artefaktem. Spring Wbudowany rozruch Tomcat wymaga przebudowania aplikacji; aktualizacja osobnej instalacji Tomcat w systemie nie spowoduje modyfikacji kopii w pakiecie aplikacji.

Po zaktualizowaniu środowiska wykonawczego sprawdź dostosowany javax.net.ssl.trustStore, samodzielnie załadowany magazyn kluczy, środowisko wykonawcze jlink, GraalVM/obraz natywny i inne formularze dostawy element po elemencie. Aplikacje, które mają już dostosowane materiały zaufania, nie mogą zakończyć sprawdzania tylko dlatego, że katalog JDK stanie się nowy.

6.4 Python: Tłumacz po tłumaczu i przetwarzanie w środowisku wirtualnym

Potwierdzono, że w ramach rzeczywistego dostawcy/kontenera można zaufać:

python - <<'PY'
import sys
import ssl
import importlib.metadata as metadata

print("executable:", sys.executable)
print("version:", sys.version)
print("openssl:", ssl.OPENSSL_VERSION)
print("verify_paths:", ssl.get_default_verify_paths())
for name in ("pip", "certifi", "Django", "urllib3", "Brotli", "litellm"):
    try:
        print(name + ":", metadata.version(name))
    except metadata.PackageNotFoundError:
        print(name + ": not installed")
PY

python -m pip --version
python -m pip check

Ten skrypt zbiera jedynie informacje i nie przeprowadza określania kwalifikacji wersji. ssl.get_default_verify_paths() to domyślna informacja o ścieżce i nie może udowodnić, że wszyscy klienci innych firm korzystają z tego samego magazynu zaufanych certyfikatów; należy to potwierdzić na podstawie konfiguracji aplikacji.

Po zakończeniu zaufanej aktualizacji rozruchowej pip z załącznika S37 zaktualizuj zależności certyfikatów zgodnie z ograniczeniami projektu, na przykład:

python -m pip install --upgrade 'certifi>=2026.10.19'

# 仅适用于当前就选择 Django 5.2 的项目
python -m pip install --upgrade 'Django>=5.2.18,<5.3'

python -m pip check

Plik wymagań/blokady projektu musi zostać zaktualizowany w tym samym czasie, w przeciwnym razie przy następnym wdrożeniu może zostać przywrócona stara wersja. Korzystając z uv, Poetry lub repozytorium pakietów korporacyjnych, użyj istniejących procesów blokowania i publikowania; nie modyfikuj ręcznie pakietów bezpośrednio w kontenerze produkcyjnym.

Istniejący przepływ pracy pip-audit projektu można wykorzystać do sprawdzenia znanych luk w zależnościach w zaufanym środowisku; nie jest to skaner złośliwego kodu i nie obejmuje wszystkich zagrożeń związanych z interpreterem, biblioteką systemową i zaufanym magazynem. S44

Nie zaleca się zmuszania systemu /usr/bin/python3 do wskazywania nowej, skompilowanej wersji. Używaj aktualizacji zabezpieczeń wersji lub środowisk wykonawczych izolacji projektu, aby uniknąć psucia narzędzi zarządzania opartych na systemie Python. Jest to wybór wynikający z implementacji i nie stanowi dodatkowego wymogu naprawy tej luki.

6.5 Odbuduj i zastąp działającą instancję

W ramach całkowitej zmiany zaleca się podjęcie następujących kroków:

Uzyskaj łatkę z oryginalnego zaufanego źródła i zapisz wersję/skrót oraz blokadę zależności.
Zwróć kluczowe funkcje w środowisku zbliżonym do produkcyjnego i potwierdź, że rozszerzenia natywne są kompatybilne z JVM/framework.
Zaktualizuj środowisko wykonawcze, zależności aplikacji i rzeczywisty magazyn zaufania; odśwież obraz bazowy i system CA dla kontenera, a nie tylko ponownie wykorzystaj starą warstwę.
Odbuduj aplikacje i obrazy oraz na bieżąco zastępuj instancje usług, procesów roboczych, konsumentów kolejek i zaplanowanych zadań.
Sprawdź ponownie wersję i konfigurację w nowej działającej instancji i potwierdź, że wszystkie stare kopie zostały zakończone.
Obserwuj współczynniki błędów, opóźnienia, błędy CPU/pamięci, błędy uzgadniania TLS i awarie procesów.

Wycofywanie powinno dać pierwszeństwo zachowaniu bezpiecznego środowiska wykonawczego i zależności poprawek oraz wycofywaniu konfiguracji aplikacji lub zmian biznesowych. Jeśli musisz wrócić do starego produktu z lukami, należy jednocześnie przywrócić odpowiednie ograniczenia wejścia oraz jasno określić osobę odpowiedzialną i minimalny okres odzyskiwania.

7. Tymczasowe środki łagodzące i wybór poprawek

7.1 Granica zasięgu środków tymczasowych

Poniżej znajdują się sugestie wdrożeniowe w oparciu o ogłoszone warunki użytkowania. O ile nie zostanie odnotowany oficjalny plan, sprzedawca nie gwarantuje, że wszystkie warianty będą mogły zostać całkowicie zablokowane.

ryzyko	Środki tymczasowe, które można podjąć	Część, której na tej podstawie nie można uznać za ukończoną
Dekodowanie Brotli	Zatrzymaj dekodowanie niezaufanego wejścia; sprawdź automatyczną dekompresję przychodzącą i wychodzącą	Przychodzące WAF lub wyłączenie kompresji odpowiedzi nie obejmuje wszystkich wpisów dekodujących S3
Next.js typed arrays RCE	Uaktualnij natychmiast; w razie potrzeby tymczasowo odizolować dotknięte usługi	Nie ma oficjalnego, niezawodnego, uniwersalnego obejścia problemu S9
Next.js SVG RCE	Oficjalny plan: upewnij się, że rzeczywisty ostry ≥0.35.5; zawiesić odpowiednie punkty wejścia optymalizacji, jeśli pozwala na to biznes	Nie obejmuje innych problemów Next/RSC S11
Tomcat Dziedzina / HTTP/2 / AJP	Odizoluj odpowiednią ścieżkę i zamknij niepotrzebne złącza	Nadal potrzebujesz odpowiedniego pakietu naprawczego oddziału S21 S22 S23
GraphQL Deserializacja	Zawieś dotknięte pola połączeń; ograniczaj niezaufanych rozmówców	Tylko limit długości żądania nie może rozwiązać problemu typu/deserializacji S25
Spring embedded LDAP	Wyłącz, gdy nie jest potrzebny; ograniczyć zasięg prawdziwego portu nasłuchowego	Nadal należy sprawdzić domyślną tożsamość administracyjną i integralność katalogu S27
CPython SNI UAF	Oficjalny plan: Zachowaj odpowiednie silne referencje SSLContext do końca usługi	Wszystkie ścieżki tworzenia/przełączania muszą być pokryte S29
Pomiń nazwę hosta Python	Oficjalne rozwiązanie: poprawnie przekaż oczekiwaną nazwę_hosta serwera	Nie można po prostu sprawdzić flagi check_hostname lub zignorować ostrzeżenia S30 S31
Nierzetelny tar	Wyłącz wyodrębnianie/poddaj kwarantannie, odrzuć niepotrzebne linki i wpisy urządzeń	Ani filtry, ani przydziały zasobów nie są uniwersalnymi piaskownicami. S32 S40 S45
Zdarzenie zaufania certyfikatu	Zaktualizuj poprawny materiał CA; Zaufanie Java można ograniczyć zgodnie z oficjalnymi środkami zaradczymi	Wyłączenie weryfikacji TLS zwiększa ryzyko S19 S37

7.2 Wybierz poprawkę w oparciu o metodę dostawy

Sposób dostawy	Ustal priorytety metod naprawy	Dowody, które należy zachować
Środowisko wykonawcze zarządzane przez dystrybucję	Odpowiednie aktualizacje zabezpieczeń producenta	Pełna wersja pakietu, ogłoszenie, źródło repozytorium
Oficjalny menedżer plików binarnych/runtime	Oficjalne wydanie zabezpieczeń z tego samego oddziału	Wersja, źródło i skrót, rzeczywista ścieżka wykonania
Samokompilowany Node / CPython	Oficjalna wersja źródłowa odpowiedniego oddziału lub pełny zestaw poprawek dostawcy	Zestaw zatwierdzeń, parametry kompilacji, biblioteki zależne i wyniki regresji
Spring / Next / Django	Kompatybilny z aktualizacjami w oddziałach, odbudową blokad zależności i aplikacjami końcowymi	Ostateczne drzewo zależności, aktualna wersja w JAR/pakiet/obraz
Niestandardowy magazyn zaufania	Oficjalny plan wypłat lub aktualizacja dostawcy potwierdzająca wycofanie	Rzeczywista ścieżka użytkowania, zmiana materiału, testy powodzenia i odrzucenia TLS
Zagrożone środowisko	Odbuduj na podstawie czystych i godnych zaufania produktów i przeprowadź osobne badanie incydentów	Historyczne podsumowanie pakietu/obrazu, zapis instalacji, zapis rotacji poświadczeń

7.3 Kluczowy mechanizm poprawek i skupienie się na przeglądzie

Brotli: zwraca uwagę, czy przed wejściem do kompilacji zakończono sprawdzanie granic i zwracanie błędów natywnego statusu dekodowania; jedynie wymiana pakietu JavaScript nie może zmienić kodu skompilowanego statycznie do Node. S4
Node DNS/TLS: koncentruje się na odrzucaniu danych wejściowych, normalizacji adresów, rozróżnieniu między tożsamościami IP SAN i DNS oraz wywołaniu zwrotnym/obietnicy DNS analiza ścieżki i test dopasowania nazwy hosta TLS. S5 S6
Tomcat JNDIRealm: koncentruje się na tym, czy proces uwierzytelniania faktycznie weryfikuje poświadczenia, a nie tylko na uzyskaniu kontekstu katalogu; nadanie priorytetu oficjalnej wersji i nietraktowanie zastąpienia pojedynczego pliku źródłowego jako kompletnej łatki binarnej. S24
CPython ssl: koncentruje się na własności referencyjnej Python i cyklu życia bazowego SSLContext; wrap_bio() wykonuje backporty, mając różnice w kompatybilności gałęzi i musisz przeczytać rzeczywistą implementację używanej gałęzi. S31 S47
Certificate distrust: Takie aktualizacje mogą wyglądać na zaufane materiały lub odrzucać zmiany na listach, a nie oczywiste zmiany w interfejsie API. Ta sama partia Node zawiera również mechanizm odrzucający wadliwego półproduktu CA; odpowiednie źródła zaufania Java i Python nadal wymagają osobnej weryfikacji. S19 S37 S46

Niezależny Brotli należy również sprawdzić wiązanie. Udostępniono usługę Google Upstream 1.0.10 / 1.1.1 / 1.2.1 tego samego dnia, aby naprawić CVE-2026-111497 . Python rozszerzenia natywne lub artefakty JNI, które osadzają tę samą implementację C, której dotyczy problem, muszą zostać niezależnie zaktualizowane/przebudowane; nie można wnioskować, że wszystko jest czyste Java ma to wpływ na dekodery i nie można zakładać, że nastąpi aktualizacja Node automatycznie zastępuje kopie w innych językach. S42

8. Weryfikacja i kontrole uzupełniające

8.1 Minimalna lista kontrolna weryfikacji

Sprawdź elementy	Wymagane dowody
czas wykonania	Pełna wersja lub dowód backportu dostawcy jest poprawny w rzeczywistym procesie/kontenerze
zależności aplikacji	Produkty Next/RSC/sharp, Tomcat/Spring i Django/certifi w ostatecznym wdrożeniu osiągnęły odpowiedni próg
Zakres wymiany	Wszystkie kopie robocze/JVM/kontenerowe i zadania w tle zostały zastąpione nowymi, a stare instancje zostały zakończone.
TLS	Prawidłowe certyfikaty domeny powiodły się; niedopasowane nazwy hostów i nieprawidłowe łańcuchy nie działają zgodnie z zasadami; niestandardowe magazyny zaufania są uwzględnione
eMudhra brak zaufania	Łańcuch certyfikatów zbudowany przez produkt pośredni CA, którego dotyczy problem, został odrzucony w rzeczywistym czasie wykonywania lub istnieją dowody na to, że wdrożono kompilację zabezpieczeń/odpowiednią listę odrzuconych konkretnego dostawcy; sprawa nie może zostać zamknięta w oparciu o ogólny test TLS lub skrócony numer wersji Java 8.
Dekodowanie i obrazy Node	Dostępne są funkcje normalnej skompresowanej odpowiedzi, przesyłania, optymalizacji obrazu i RSC; obowiązują zasady dotyczące niezaufanych źródeł
Java Uwierzytelnianie i izolacja	Błędne hasło odrzucone; niezależne, współbieżne żądania asynchroniczne użytkownika bez mieszania tożsamości/odpowiedzi; LDAP słucha zgodnie z oczekiwaniami
Python SNI / Archiwum	Normalna działalność w wielu domenach TLS jest stabilna; archiwizacja odrzuca przechodzenie ścieżek i niedozwolone łącza, a pliki poza katalogiem nie są modyfikowane
Regresja danych i funkcjonalna	Stronicowanie, zapytania przestrzenne, sprawdzanie uprawnień i zadania w tle przeszły istniejące testy projektu
Zasoby i obserwacje	Nie ma nietypowego wzrostu liczby błędów CPU, pamięci, współczynnika błędów, opóźnień i błędów TLS.
Identyfikowalność	Oszczędzaj czas aktualizacji, podsumowanie pakietów/obrazów, zmiany konfiguracji, wyniki weryfikacji i nierozwiązane elementy

Są to zalecenia dotyczące akceptacji implementacji i nie wymagają tworzenia skryptu ataku dla każdego CVE. Weryfikacja obejmująca awarie, wyczerpanie zasobów i przekroczenie zakresu archiwum powinna wykorzystywać wcześniejsze testy regresyjne lub dane testowe kontrolowane przez projekt w izolowanym środowisku.

8.2 Łatanie i badanie włamań to różne zadania

Sprawdź istniejące dzienniki pod kątem nietypowych błędów dekodowania, awarii procesów roboczych/JVM, podejrzanych zapisów plików, zmian danych w katalogach, wyjątków uwierzytelniania, żądań wychodzących i zapisów użycia poświadczeń. Znaki te należy oceniać w kontekście: awaria lub OOM nie są dowodem udanego wykorzystania; brak alertów nie oznacza, że system nie był dotknięty.

W przypadku wykrycia nieautoryzowanych modyfikacji, naruszonych poświadczeń lub potwierdzonych złośliwych zależności należy zabezpieczyć dowody, odizolować odpowiednie instancje, przenieść dane uwierzytelniające z zaufanego środowiska, których to dotyczy, i odbudować system. Łatka nie unieważni tokenów zdobytych przez atakującego ani nie przywróci zmodyfikowanych danych.

9. Incydent związany z bezpieczeństwem łańcucha dostaw: kompromis LiteLLM 1.107.0

**Data oficjalnego potwierdzenia: 2026-10-21 r.**LiteLLM poinformował, że jego plan wydań został naruszony. litellm==1.107.0 firmy PyPI i niektóre produkty Docker/GHCR z tego samego okresu zawierały złośliwy kod służący do kradzieży tajnych informacji i zdalnego sterowania, w związku z czym powiązane produkty zostały wycofane. S41

Aby określić wpływ, należy sprawdzić historyczne zapisy instalacji i zestawienie obrazów; etykiety takie jak latest, main-latest i main-stable wskazują obecnie na czyste obrazy, co nie dowodzi, że produkty wyciągnięte w momencie zdarzenia były czyste. Oficjalna rekomendacja w tamtym czasie brzmiała: tymczasowo przypiąć 1.106.2; to zalecenie zostało oparte na tym incydencie, a inne komunikaty dotyczące bezpieczeństwa nadal wymagają sprawdzenia podczas wdrażania. S41

W środowiskach, w których zainstalowano lub uruchomiono powiązane produkty:

Izoluj i przechowuj zapisy instalacji, obrazy i dzienniki oraz sprawdzaj je w czystym środowisku.
Nie uruchamiaj najpierw Python/pip w podejrzanym środowisku; złośliwy .pth / sitecustomize.py może zostać uruchomiony ponownie po uruchomieniu.
Odbuduj hosty, Venvs/kontenery z zaufanych źródeł; nie można po prostu odinstalować lub obniżyć wersji pakietów.
Unieważnij/zamień dane uwierzytelniające w chmurze, klucze dostawcy LLM, klucze LiteLLM i dane uwierzytelniające bazy danych w oparciu o rzeczywistą dostępność i przejrzyj nieprawidłowe użycie. S41

Jest to potwierdzony incydent w łańcuchu dostaw i podczas postępowania z nim należy wziąć pod uwagę wykonanie złośliwego kodu, wyciek danych uwierzytelniających i ryzyko utrzymywania się. Na dzień 23 października 2026 r. urzędnicy nadal prowadzili dochodzenie w sprawie pierwszego włamania.

Dodatek: Cytowane źródła i linki

Następująca data weryfikacji źródła to 2026-10-23, obejmująca oficjalne ogłoszenie dotyczące bezpieczeństwa projektu, oficjalne repozytorium kodów i instrukcje dostawcy. Tekst główny [Sx] odpowiada temu załącznikowi; podczas wykonywania aktualizacji należy sprawdzić, czy dostawca nie wydał kolejnych wersji.

S1 — Node.js: 2026-10-21 Informacja dotycząca bezpieczeństwa

Cel: Cztery środowiska wykonawcze High wpływające na gałęzie, październikowa aktualizacja zabezpieczeń.
Źródło: Oficjalny biuletyn bezpieczeństwa

S2 — Node.js: Oficjalne instrukcje wydania dla trzech linii konserwacji

Cel: Sprawdź 22.23.4, 24.22.1, 26.12.1 i rzeczywiste połączone poprawki.
Źródło: Node.js 22.23.4
Źródło: Node.js 24.22.1
Źródło: Node.js 26.12.1

S3 — Vercel: Node.js Brotli RCE poradnik bezpieczeństwa

Cel: Warunki dekodowania ruchu przychodzącego/wychodzącego, granica zasięgu WAF, status Node 20.
Źródło: Node.js security advisory: Brotli decoder RCE

S4 — Node.js: Brotli oficjalne przesłanie poprawki

Cel: Podstawa implementacji natywnego sprawdzania dekodowania i propagacji błędów.
Źródło: Brotli Zatwierdzenie poprawki 49dff6f57a

S5 — Node.js: Łatka normalizująca adres TLS

Cel: Weryfikacja tożsamości certyfikatu numerów pełnej szerokości i niestandardowych IP.
Źródło: IP normalization regression Łatka
Źródło: odrzuca patchowanie niestandardowego adresu IP

S6 — Node.js: Łatka weryfikacyjna DNS NUL

Cel: Odrzucenie danych wejściowych i pokrycie regresji.
Źródło: dns.resolve Poprawka weryfikacyjna danych wejściowych

S7 — Node.js: 2026-07-29 Uwaga dotycząca bezpieczeństwa

Cel: wyczerpanie pamięci HTTP/2, UAF i luki w zabezpieczeniach modelu uprawnień.
Źródło: July 2026 Security Releases

S8 — Next.js: aktualizacja zabezpieczeń 2026-10-14

Cel: Ujednolicenie planu bazowego aktualizacji i trzech kluczowych zagrożeń.
Źródło: Next.js Security Update for Upstream Vulnerabilities

Źródło: S9 — Next.js：typed arrays / use cache RCE

Przeznaczenie: GHSA-673q-mjm6-r5xr; wpływa na interwał, stan, wynik i status obejścia.
Źródło: Next.js Oficjalny biuletyn bezpieczeństwa

Źródło: S10 — React：React Server Components RCE

Przeznaczenie: GHSA-xqc2-xf4c-x3h3; dotknięte i naprawione wersje trzech pakietów RSC.
Źródło: React Oficjalny biuletyn bezpieczeństwa

Źródło: S11 — Next.js：SVG Image Optimization RCE

Przeznaczenie: CVE-2026-96889 / GHSA-2464-fhr4-w9xw; glibc, ostre i oryginalne granice wersji.
Źródło: SVG Oficjalny biuletyn dotyczący optymalizacji obrazu

Źródło: S12 — Next.js：Server Actions DoS

Przeznaczenie: GHSA-p3m5-59mp-jv5r; wpływa na warunki, wersje i oceny.
Źródło: Server Actions DoS Oficjalny biuletyn bezpieczeństwa

S13 — Next.js: AVIF Optymalizacja obrazu RCE

Cel: 2026-08-25, GHSA-2xp9-vwfh-vxw4.
Źródło: AVIF Oficjalny biuletyn bezpieczeństwa

Źródło: S14 — Next.js：Windows RCE

Cel: 2026-08-25, CVE-2026-75604/GHSA-p293-qw3h-jr36.
Źródło: Windows RCE Oficjalny biuletyn bezpieczeństwa

Źródło: S15 — Next.js：next/og ImageResponse RCE

Cel: 2026-09-22, GHSA-vcvr-r3jv-pc5j; Różnica pomiędzy Node i Edge.
Źródło: ImageResponse Oficjalny biuletyn bezpieczeństwa
Źródło: Informacje o wersji z 22 września

Źródło: S16 — Oracle: October 2026 CPU

Cel: matryca ryzyka Java SE, ilość poprawek i obowiązujące warunki.
Źródło: Oracle Critical Patch Update – October 2026
Źródło: Oracle Java SE CPU Lista wersji

S17 — Oracle: CVE-2026-91403 alarm pozapasmowy

Cel: 2026-10-21, ryzyko zaufania certyfikatu JSSE, produkty, których to dotyczy i CVSS 3.1 9.1.
Źródło: Oracle Security Alert

S18 — Oracle: Oficjalna wersja JDK i pobierz

Cel: rozróżnienie między CPU z 20 października a wersją pozapasmową z 21 października; rozróżnić ograniczenia krótkiej wersji Java 8.
Źródło: JDK release list
Źródło: Oracle Java Strona pobierania

S19 — Oracle: eMudhra tymczasowy plan wycofania

Cel: aktualizacja 2026-10-22; dwa certyfikaty główne, narzędzie do kluczy, niestandardowy magazyn zaufanych certyfikatów i sprawdzanie unieważnień.
Źródło: Distrusting eMudhra Intermediate Certificates in Oracle JDK

S20 — Eclipse Adoptium: Zwolnij rekord kompilacji

Cel: Temurin zostaje przepakowany w związku z incydentem związanym z certyfikatem; przyrostka wersji Oracle nie można zastosować mechanicznie.
Źródło: Adoptium Release Scorecards

S21 — Apache Tomcat 9 Uwaga dotycząca bezpieczeństwa

Cel: dokładnie 9-gałęziowy interwał, którego dotyczy problem z poprawką 9.0.123.
Źródło: Tomcat 9 vulnerabilities

S22 — Apache Tomcat 10 Uwaga dotycząca bezpieczeństwa

Cel: precyzyjny interwał rozgałęzienia 10.1 i naprawa 10.1.61; 10.0 EOL.
Źródło: Tomcat 10 vulnerabilities

S23 — Apache Tomcat 11 Uwaga dotycząca bezpieczeństwa

Cel: Trzy pozycje Important, 11.0.27, AJP mający zastosowanie zakres i data ujawnienia/wydania.
Źródło: Tomcat 11 vulnerabilities

S24 — Apache Tomcat: Zatwierdzenie poprawki JNDIRealm

Cel: Formalna podstawa do naprawy luk weryfikacyjnych certyfikacji.
Źródło: JNDIRealm Zatwierdzenie poprawki

Źródło: S25 — Spring：GraphQL CVE-2026-59285

Cel: 2026-08-20, wymagany, 2.0.5 OSS / 2.0.4.1 Naprawa komercyjna.
Źródło: Spring for GraphQL Unsafe Deserialization

Źródło: S26 — Spring：GraphQL CVE-2026-41699

Cel: wcześniejszy próg poprawki, aby wyjaśnić, dlaczego nie można pozostać przy starym poziomie bazowym.
Źródło: 6 Miesiąc GraphQL Biuletyn Bezpieczeństwa

Źródło: S27 — Spring Security：CVE-2026-59270

Cel: Osadź UnboundID LDAP, znaną tożsamość zarządzania i rozróżnij OSS/wersję komercyjną.
Źródło: Spring embedded LDAP Biuletyn Bezpieczeństwa

Źródło: S28 — Spring Security：CVE-2026-47841

Cel: uwierzytelnianie użytkownika WebAuthn, serializacja sesji i przesłanka ataku.
Źródło: WebAuthn Biuletyn Bezpieczeństwa

S29 — PSF: CVE-2026-19445 Niezależny doradca ds. bezpieczeństwa

Cel: 2026-09-30, Critical, SNI Warunki i środki tymczasowe wymienione w SSLContext.
Źródło: SSLContext UAF Oficjalne ogłoszenie

S30 — PSF: CVE-2026-19553 Niezależny doradca ds. bezpieczeństwa

Cel: 2026-09-30, High, brak nazwy hosta i jawne ograniczenie parametrów.
Źródło: wrap_bio Oficjalne ogłoszenie weryfikacji nazwy hosta

S31 — CPython: oficjalna łatka wrap_bio i backport 3.12

Cel: 3.10 — polityka zgodności ostrzeżenia 3.12, różnica między None a pustym ciągiem znaków.
Źródło: PR #158503
Źródło: 3.12 Zasypka PR #158513
Źródło: 3.15 Zasypka PR #158511

S32 — PSF: CVE-2026-82049 Niezależny doradca ds. bezpieczeństwa

Cel: 2026-09-14, High, kombinacja linków, modyfikacja metadanych i ujawnienie treści.
Źródło: link do pliku tar omija oficjalne ogłoszenie

S33 — CPython: Oficjalna aktualizacja zabezpieczeń pod koniec września/na początku października

Cel: minimalna wersja poprawki, metoda dystrybucji kodu źródłowego i zwolnienie 3.14 w przypadku problemów związanych z plikami tar.
Źródło: Python Instrukcje dotyczące udostępniania zabezpieczeń między oddziałami
Źródło: Python 3.11.17
Źródło: Python 3.12.15
Źródło: Python 3.13.16
Źródło: Python 3.14.8

S34 — CPython: 3.10 ostatnie bezpieczne wydanie

Cel: 3.10.22 i koniec cyklu życia wyższego szczebla.
Źródło: Python 3.10.22

S35 — CPython: 2026-10-21 wersja do konserwacji awaryjnej

Przeznaczenie: 3.13.17 / 3.14.9 / 3.15.1, wbudowane aktualizacje pip i certifi, istniejące wymagania Venv.
Źródło: Python 3.13.17
Źródło: Python 3.14.9
Źródło: Python 3.15.1

S36 — certifi: Ogłoszenie o braku zaufania do certyfikatu emSign

Cel: 2026-10-20, GHSA-6q48-6c7w-9gw2, Critical, brak znanego CVE.
Źródło: certifi Oficjalny biuletyn bezpieczeństwa

S37 — PSF: Wpływ eMudhra / emSign na użytkowników Python

Cel: zalecenie certifi .19, linia bazowa pip/uv, polecenie aktualizacji zaufanego rozruchu za pomocą SHA-256.
Źródło: PSF Oficjalne instrukcje dotyczące wydarzeń i aktualizacji

Polecenie aktualizacji rozruchu pip podane w oficjalnych instrukcjach cytowanych przez S37 jest następujące. Używać wyłącznie w środowiskach Python, które zostały potwierdzone jako godne zaufania; jeżeli istnieje podejrzenie zatrucia zgodnie z sekcją 9, należy najpierw odizolować i odbudować zgodnie z procesem zdarzenia. Naprawia skrót zawartości koła, a następnie aktualizuje inne zależności zgodnie z procesem projektu.

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

S38 — Django: 2026-08-04 bezpieczne zwolnienie

Zastosowanie: CVE-2026-15307, GeoDjango Warunki eksploatacji, poprawki wstępne i zmiany kompatybilności.
Źródło: Django 6.0.8 / 5.2.17

S39 — Django: 2026-10-06 bezpieczne wydanie

Przeznaczenie: CVE-2026-87890, geometria DoS zbrojenie późniejsze z aktualnie wybraną linią bazową.
Źródło: Django 6.1.2 / 6.0.9 / 5.2.18

S40 — PSF / CPython: Najnowsza uwaga dodatkowa tar_filter

Cel: 2026-10-22, CVE-2026-114583 (Medium); Połączenie PR nie oznacza, że została wydana oficjalna wersja serwisowa.
Źródło: PSF Niezależne ogłoszenie
Źródło: CPython Łatka PR #160098

S41 — LiteLLM: Oficjalny raport z incydentu w łańcuchu dostaw, 21 października

Cel: produkt zanieczyszczony 1.107.0, podsumowanie historyczne, rekonstrukcja izolacji i utylizacja poświadczeń.
Źródło: Contained: LiteLLM v1.107.0 Compromised

S42 — Google Brotli: oficjalna, bezpieczna wersja

Cel: Niezależna podstawa weryfikacji Brotli 1.0.10 / 1.1.1 / 1.2.1 i wielojęzycznej wbudowanej kopii.
Źródło: Brotli releases

S43 — mise: użyj oficjalnej dokumentacji polecenia

Cel: Określenie wersji narzędzia i semantyki poleceń konfiguracji globalnej.
Źródło: mise use

S44 — PyPA: pip – oficjalny projekt audytu

Cel: Python Cel i granice możliwości audytu podatności na zależności.
Źródło: pip-audit

S45 — Python: dokument filtrujący wyodrębnianie pliku tar

Cel: strategia danych, domyślne zmiany zachowania i ograniczenia, które nie mogą zastąpić piaskownicy.
Źródło: tarfile extraction filters

S46 — Node.js: Pośredni mechanizm odrzucający CA

Cel: To przetwarzanie łańcucha zaufania powiązane z eMudhra nie jest równoznaczne z kryptograficznym unieważnieniem wszystkich certyfikatów głównych.
Źródło: Node.js PR #66871

S47 — CPython: SNI UAF uwagi techniczne i poprawki

Cel: referencyjny cykl życia, specjalne warunki kompilacji i wycofywanie gałęzi.
Źródło: #156293
Źródło: PR #158504
Źródło: 3.15 Zasypka PR #158514