Luki w zabezpieczeniach NGINX: przyczyny, poprawki i weryfikacja produkcji

Data artykułu historycznego: 2026-10-14 (data ujawnienia i zwolnienia zabezpieczeń). Sprawdzono źródła i uzupełniono informacje poprzez 2026-10-27.

Ten artykuł jest archiwizowany według daty wydarzenia; Poniżej znajdują się aktualizacje wersji i wydań wydane po 14 października. Odbiorcy: personel obsługujący i konserwujący stronę internetową NGINX Open Source / NGINX Plus oraz odwrotne proxy, personel odpowiedzialny za bezpieczeństwo, opiekunowie dystrybucji, a także inżynierowie, którzy samodzielnie kompilują NGINX i utrzymują moduły stron trzecich.

W tym artykule skupiono się na pięciu podstawowych lukach w zabezpieczeniach NGINX, które zostały ujawnione i intensywnie naprawione 14 października 2026 r., a także omówiono reprezentatywne luki w zabezpieczeniach pamięci i integralności żądań od maja do września 2026 r. Treść obejmuje warunki wyzwalania, przyczyny na poziomie kodu, zakres wpływu, przepływ pracy zaradczej, krótkoterminowe środki łagodzące, oficjalną implementację poprawek, backporty do starszych oddziałów i weryfikację produkcji. Odniesienia, takie jak S1, prowadzą do załącznika źródłowego. Przykładowe konfiguracje służą jedynie do zilustrowania pomysłów dotyczących wdrożenia i audytu i powinny zostać zweryfikowane na podstawie rzeczywistej wersji, dziedziczenia konfiguracji, zależności i możliwości biznesowych przed wdrożeniem.

TL;DR: Działania priorytetowe

1. Nadaj priorytet aktualizacjom zabezpieczeń. W przypadku pakietów nginx.org Open Source zaktualizuj gałąź Stable 1.30 do co najmniej 1.30.6, a gałąź Mainline 1.31 do co najmniej 1.31.7.. Na dzień weryfikacji najnowszym jest 1.31.8 Wersja Mainline. Są to oddzielne wartości bazowe dla gałęzi; nie porównuj ich liczb w różnych oddziałach. S1S2
2. Sprawdź instalacje dystrybucyjne według pełnej wersji pakietu. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 mają backporty dostawców; Debian 13 (trixie) wymaga co najmniej 1.26.3-3+deb13u10. Podczas weryfikacji pakiet Debian 12 (bookworm) 1.22.1-9+deb12u10 jest nadal oznaczony jako uszkodzony. Sprawdź każdy CVE; zalecenie Debian 13 nie stwierdza, że ​​Debian 12 zostało naprawione. S13S14S15
3. Przeprowadź audyt pięciu kombinacji konfiguracji: alias + rewrite + $request_filename, map + wyrażenie regularne + ocena zmiennej, aio + ssi + include virtual, HTTP/3 z proxy_request_buffering on i ssl_session_cache shared:... z automatyczną rotacją kluczy biletu sesji TLS. Sama obecność dyrektywy nie stanowi o możliwości wykorzystania; ocenić ścieżkę żądania i zakres konfiguracji. S1S3S4
4. Wymień wszystkie stare procesy i kontenery. Uruchom nginx -t, a następnie uruchom ponownie usługę lub wykonaj wdrożenie stopniowe o wysokiej dostępności. Potwierdź, że stare procesy master/worker zostały zakończone; Sam nginx -s reload nie dowodzi, że działający plik binarny uległ zmianie.
5. Sprawdź rzeczywiste punkty końcowe: HTTP/1.1, HTTP/2, HTTP/3, jeśli są włączone, przesyłanie przez serwer proxy i treść żądań API, uwierzytelnianie certyfikatu mTLS, strony SSI i dzienniki dostępu. Rejestruj pochodzenie pakietu, wersję, podsumowanie obrazu, uruchomione procesy i wyniki dla każdego punktu końcowego.
6. Jeśli natychmiastowa aktualizacja jest niemożliwa, usuń odpowiednie warunki wyzwalające: wyłącz niepotrzebne odniesienia do zmiennych SSI/AIO lub HTTP/3, przejrzyj podatne na ataki alias/rewrite/map i oceń tymczasowe ssl_session_tickets off; pod kątem dotkniętych Usługi mTLS. WAF, ASLR, limity szybkości i zmiany konfiguracji obejmują tylko niektóre warunki i nie mogą zastąpić oficjalnych poprawek. S3S4S8S12

1. Przegląd podatności i ocena ryzyka

NGINX wypuścił 1.30.6 (Stable) i 1.31.7 (Mainline) 14 października 2026 r., naprawiając pięć problemów związanych z bezpieczeństwem. Trzy dotyczą przepełnienia sterty lub użycia po zwolnieniu i uzyskały wyniki F5 CVSS v4.0 na poziomie 9.2 / Krytyczny. Pozostałe dwa wpływają na integralność żądania HTTP/3 i uwierzytelnianie certyfikatu klienta TLS. S1S2S3

Rozróżnij systemy oceny: nginx.org wymienia wszystkie pięć problemów jako medium, podczas gdy F5 CVSS v4.0 i niektóre agencje bezpieczeństwa narodowego klasyfikują trzy problemy z pamięcią jako krytyczne. Nie oznacza to, że wszystkie pięć umożliwia bezwarunkowe zdalne wykonanie kodu. Konfiguracja, osiągalność ruchu i warunki pozostające poza kontrolą atakującego mają znaczenie. Uszkodzenie pamięci i niezawodny RCE to różne poziomy dowodów. S1S3S4

CVE	Problemy techniczne i typowe warunki wyzwalania	wpływ na rdzeń	Ocena i utylizacja
CVE-2026-15176	alias mapowanie ścieżki + rewrite zmiana URI + ocena $request_filename	Przepełnienie bufora sterty, awaria Worker; potencjał RCE pod pewnymi warunkami	F5 CVSS v4.0 9.2; nadaj priorytet rozwiązywaniu problemów
CVE-2026-93479	Ocena skryptu HTTP/Stream, w szczególności przechwytywanie wyrażeń regularnych map i katalog root, odsyłacze do zmiennych dziennika	Zarezerwowany bufor zostanie nadpisany, a sterta przepełniona; potencjał RCE pod pewnymi warunkami	F5 CVSS v4.0 9.2; istnieje ryzyko regresji po poprzednich naprawach
CVE-2026-97205	SSI wirtualny obejmuje i AIO/operację asynchroniczną; przekroczenie liczby zaległych operacji	Use-After-Free, awaria Worker, uszkodzenie pamięci; potencjał RCE	F5 CVSS v4.0 9.2; wymaga konfiguracji innej niż domyślna
CVE-2026-95101	HTTP/3 Nieznana ramka jest pofragmentowana w buforach, włączone jest buforowanie treści żądania proxy	Nieprawidłowe wstrzykiwanie bajtów innych niż DATA do treści żądania nadrzędnego, prawdopodobnie z pominięciem limitu rozmiaru treści żądania	Luka ta wpływa na integralność żądań. Sam w sobie nie zapewnia zdalnego wykonania kodu (RCE).
CVE-2026-97629	Współdzielona pamięć podręczna sesji TLS, automatyczna rotacja kluczy i kopiowanie kluczy Worker	Fałszowanie biletów na sesję; w przypadku usługi mTLS, której dotyczy problem, może wystąpić obejście uwierzytelniania certyfikatu klienta	Szczególną uwagę należy zwrócić na wpływ biznesowy typu uwierzytelniania certyfikatu API

Powyższy wynik CVSS jest przyznawany przez F5 przy użyciu v4.0; ta sama luka może wykazywać różną wagę w CVSS 3.1, nginx.org, własnych klasach i ocenach ważności dystrybucji. S1S3S4

1.1 Nadaj priorytet ekspozycji na wdrożenie, a nie samym wynikom CVE

Formularz wdrożenia	Kluczowe punkty śledztwa	Zalecenia dotyczące priorytetu utylizacji
Odwrotne proxy sieci publicznej, w tym niestandardowe rewrite, alias i złożone map	CVE-2026-15176, CVE-2026-93479 i przepisywanie/mapowanie luk w zabezpieczeniach od maja do lipca	P0: Natychmiastowa kontrola i aktualizacja
API / Płaszczyzna zarządzania wykorzystująca certyfikat klienta jako jedyne lub główne uwierzytelnienie wejścia	Konfiguracja biletu sesji i współdzielonej pamięci podręcznej CVE-2026-97629	P0: Natychmiast potwierdź granicę uwierzytelniania i zaktualizuj
Zapewnij zewnętrzne przesyłanie HTTP/3, interfejs zmiany statusu, klasę transakcji API	CVE-2026-95101, zwłaszcza treść żądania jest przekazywana do backendu	P0/P1: Ułóż według ważności biznesowej
SSI Strona dynamiczna lub asynchroniczne we/wy pliku	CVE-2026-97205	P1: Potwierdź warunki kombinacji i napraw tak szybko, jak to możliwe
Tylko strony statyczne + proste odwrotne proxy HTTP/1.1/2	Konfiguracja i wersja nadal wymagają audytu, ale może brakować niektórych warunków CVE	P1: Zawarte w oknie aktualizacji zabezpieczeń awaryjnych
Użyj wycofanej społeczności Kubernetes ingress-nginx	Projekt wstrzymuje utrzymanie bezpieczeństwa, a ryzyko nie ogranicza się do tych pięciu CVE	Przygotuj indywidualny plan migracji kontrolera

P0/P1 to sugestie dotyczące obsługi i konserwacji podane w tym artykule dotyczące narażenia sieci publicznej i wrażliwości certyfikacji. Nie jest to oficjalna klasyfikacja CVSS i nie powinna zastępować wewnętrznej oceny aktywów przedsiębiorstwa ani zmieniać oceny ryzyka.

1.2 Wpływ na granice i uprawnienia do ataku

Główne luki w tej grupie są zlokalizowane głównie w płaszczyźnie danych NGINX: punktem wejścia ataku jest połączenie i żądanie klienta, a rzeczywisty wpływ zwykle pojawia się w procesie Worker. Jeśli spełnione są możliwe do wykorzystania warunki uszkodzenia pamięci, pozwolenie na wykonanie kodu jest zazwyczaj ograniczone przez działającego użytkownika, ograniczenia kontenera, możliwości systemu Linux, uprawnienia do montażu i sieci Worker; potencjalny RCE nie oznacza automatycznie uprawnień root ani naruszenia hosta. S4

Jednak nawet jeśli proces nie jest uprzywilejowany, może nadal mieć dostęp do poświadczeń proxy, czytelnych plików zawierających klucze prywatne certyfikatów, tokenów usług nadrzędnych, plików tymczasowych, wewnętrznego API i osiągalnych sieci. W przypadku mTLS samo obejście uwierzytelnienia może być poważną konsekwencją biznesową i niekoniecznie musi towarzyszyć wykonaniu kodu.

2. Analiza przyczyn

2.1 Poznaj trzy podatne na błędy granice w NGINX

NGINX worker to długotrwały proces sterowany zdarzeniami, który utrzymuje status żądań, operacje asynchroniczne i parsery protokołów. Ta luka obejmuje ograniczenia na trzech poziomach inżynieryjnych:

1. ocena zmiennej i wielkość pamięci muszą być spójne: rewrite Po zmianie żądania URI mapowanie ścieżki musi być zgodne z aktualnie obowiązującym location; kiedy interpreter skryptu oblicza zmienną długość, przestrzeń zapisu musi obejmować rzeczywiste obszary wyjściowe i zarezerwowane.
2. Operacje asynchroniczne muszą wydłużać cykl życia żądanej pamięci: w przypadku niedokończonych odczytów i zapisów plików, oczekiwania w pamięci podręcznej lub zadań wątków, odpowiednia pula pamięci żądań nie może zostać zwolniona z wyprzedzeniem.
3. statusu protokołu i statusu bezpieczeństwa nie można mieszać ani pomijać: HTTP/3 Długość nieznanego pomijania ramek nie może być traktowana jako długość treści żądania DATA; TLS Wszystkie kluczowe sloty biorące udział w weryfikacji podpisu muszą zostać poprawnie zainicjowane i zsynchronizowane podczas rotacji biletów sesji.

Poniższa treść opiera się na zatwierdzeniu poprawki początkowej NGINX i ogłoszeniu dostawcy wyjaśniającym mechanizm awarii, który może zostać wywołany; przykładowy fragment służy do analizy, nie jest pełnym kodem, który można bezpośrednio wykorzystać do naprawy środowiska produkcyjnego. S5S6S7S8S9

2.2 CVE-2026-15176: Mapowanie ścieżki pomiędzy alias i przepisanym URI jest nieprawidłowe.

W NGINX dopasowane location i jego alias określają ścieżkę pliku; rewrite może zmienić bieżące żądanie URI. Po przepisaniu założenia zastosowane w oryginalnym mapowaniu location mogą już nie obowiązywać.

Ścieżka przetwarzania, której dotyczy problem, nie sprawdziła odpowiednio, czy żądanie zostało przepisane podczas sprawdzania statusu alias w ngx_http_map_uri_to_path(). Jeśli po ponownym zapisaniu konfiguracja będzie nadal oceniać $request_filename, ścieżka może zostać zbudowana przy założeniach, które nie są zgodne z bieżącym stanem URI, co ostatecznie spowoduje zapis w pamięci sterty poza granicami. S5

Typowa kombinacja (używana wyłącznie jako kontrprzykład do audytu konfiguracji, wdrażanie nie jest zalecane):

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

Niebezpieczeństwo nie ogranicza się do return: set, if, add_header, log_format itp. również muszą zostać poddane audytowi, jeśli w tym samym procesie żądania zostanie uruchomiona ocena $request_filename. return w przykładzie jedynie ułatwia dostrzeżenie ścieżki stanu i nie można z niej wnioskować, że wszystkie konfiguracje produkcyjne spowodują przepełnienia. S5S10

Konsekwencje ataku: Skonstruowanie żądania może spowodować ponowne uruchomienie Worker lub przerwę w świadczeniu usług; w warunkach takich jak ASLR jest zamknięty lub można go ominąć, istnieje potencjalny RCE. Istotą łatki nadrzędnej jest odmowa ukończenia przepisanego mapowania ścieżki URI w kontekście alias, który nie jest już ważny, zamiast po prostu rozszerzania określonego bufora. S5S10

2.3 CVE-2026-93479: Niezgodność między „zarezerwowanym miejscem” a rzeczywistą zmienną długością podczas oceny skryptu

Moduły HTTP i Stream NGINX posiadają ewaluatory skryptów, które łączą ciągi literałów i wartości zmiennych w ciąg wynikowy. Przykłady zastosowań obejmują ścieżki dokumentu HTTP root, ścieżki dziennika dostępu i wyrażenia zmienne w Stream.

Niektóre konfiguracje map + wyrażenia regularne umożliwiają odczytanie przechwyconych wartości przez inne wyrażenia przed oceną zmiennej wynikowej map. W połączeniu z metodą wykonywania skryptu z zarezerwowaną długością, stara implementacja będzie z wyprzedzeniem zliczać zarezerwowane miejsce len do akumulatora o oszacowanej długości, tak że późniejsze obliczenia wskaźnika zapisu nie będą już zgodne z granicą bufora. W określonej sekwencji oceny zmiennej kolejne zapisy łańcuchów mogą zastąpić zarezerwowany obszar, powodując przepełnienie sterty. S6

elementy partycypacyjne	Dlaczego warto zwrócić na to uwagę
wyrażenie regularne w map	Ocena zmiennej przechwytującej może mieć niezależny cykl życia i zachowanie buforowania
Anonimowe przechwytywania, takie jak $1, $2 itp.	Łatwo nadpisywane przez inne wyrażenia regularne lub wyrażenia, co utrudnia śledzenie własności
Zmienne w root	Wykonanie skryptu i rezerwacja bufora podczas wyzwalania budowania ścieżki
log_format/Ścieżka dziennika dynamicznego	Ten sam typ oceny może zostać uruchomiony w dalszej części żądania
Wyrażenia skryptowe w stream	Poprawka nadrzędna modyfikuje również ngx_stream_script_run(). Nie można jedynie przejrzeć modułu HTTP.

Ważna relacja regresyjna: Kod związany z tą luką jest powiązany z poprzednimi zmianami, które naprawiły CVE-2026-42533. Oficjalne oświadczenie DSA dla Debian 13 wyraźnie stwierdza, że ​​kod, którego dotyczy problem, został wprowadzony do pakietu trixie poprzez wcześniejszą backport zabezpieczeń. Dlatego też fakt, że „zainstalowano lipcową łatę luki map” nie oznacza, że ​​październikowa poprawka CVE-2026-93479 została już uwzględniona; należy sprawdzić pełny łańcuch poprawek bezpieczeństwa. S6S14S17

Potencjalne ryzyko RCE jest tutaj związane ze środowiskiem ochrony pamięci i nie należy twierdzić, że samo wyrażenie regularne map będzie mogło zostać wykorzystane przez anonimowych atakujących. S11

2.4 CVE-2026-97205: AIO Zawijanie licznika niedokończonych operacji powoduje brak użycia

Luka ta nie polega po prostu na „włącz SSI, a otrzymasz UAF”. Klucz leży w liczbie odwołań do operacji asynchronicznych przechowywanych w głównym żądaniu.

NGINX Użyj r->main->blocked do śledzenia przetwarzania asynchronicznego, które jeszcze się nie zakończyło, w starej implementacji było to 8-bitowe; w przypadku niektórych ścieżek nie sprawdzano górnego limitu przed zwiększeniem liczby. Gdy w tym samym żądaniu głównym zgromadzi się 256 zaległych operacji, liczba może wahać się od 255 do 0. Kolejne procesy błędnie uznają, że nie ma operacji asynchronicznej uniemożliwiającej zwolnienie żądania, zwalniając w ten sposób pulę pamięci żądań, do której wciąż odwołuje się zadanie. S7

Proces awarii można podzielić na:

1. Po włączeniu powiązanej asynchronicznej ścieżki we/wy/wątku strona SSI wprowadza wiele podżądań lub operacji odczytu za pośrednictwem include virtual.
2. Zaległe operacje określonego żądania głównego są kumulowane do górnego limitu reprezentowanego przez pole licznika.
3. Zawija się 8-bitowa liczba, niepoprawnie wyrażona jako „brak oczekujących operacji”.
4. Pula pamięci żądań zostaje zwolniona, podczas gdy odczyty plików, oczekiwania w pamięci podręcznej lub wywołania zwrotne zadań wątków nadal zachowują odniesienia do niej.
5. Kolejne wywołania zwrotne asynchronicznego zakończenia uzyskują dostęp do zwolnionej pamięci, co powoduje awarie UAF, Worker lub potencjalne uszkodzenie pamięci.

Oficjalna poprawka dodaje NGX_HTTP_MAX_BLOCKED 250 do pliku nagłówkowego żądania i dodaje ograniczenia do filtra wyjściowego, odczytu pamięci podręcznej i ścieżki wątku nadrzędnego; po osiągnięciu progu operacje na zsynchronizowanych ścieżkach są wykonywane synchronicznie, a jeśli nie można ich bezpiecznie przetworzyć, dalsze dodawanie oczekujących zadań zostanie odrzucone. S7

ocena możliwości zastosowania: Należy ocenić, czy SSI, AIO, włączenie wirtualne, podżądania i powiązane operacje asynchroniczne mogą występować w połączeniu w tym samym łańcuchu żądań. Zwykle nie są to domyślne konfiguracje zwykłego statycznego serwera proxy. aio off; lub ssi off; może usunąć określone elementy wyzwalające, ale najpierw należy potwierdzić zależności funkcji biznesowych. S4S7S25

2.5 CVE-2026-95101: Nieznana ramka HTTP/3 jest mylona ze statusem treści żądania DATA

Parser ramek HTTP/3 musi rozróżnić ramki DATA (które muszą zostać przekazane do przetwarzania treści żądania HTTP) od nieznanych ramek, które należy pominąć. Podczas fragmentacji przez bufory sieciowe należy także dokładnie zachować długość nieznanych ramek.

Stara implementacja ngx_http_v3_parse_data() wykorzystywała pole st->length do zapisywania „pozostałej liczby bajtów do pominięcia” podczas pomijania nieznanych ramek, podczas gdy filtr treści żądania interpretował to samo pole jako „pozostała długość ładunku DATA”. Jeżeli nieznana ramka obejmuje wiele wywołań analizy, następna partia bajtów po przerwaniu analizy może zostać błędnie uznana za część treści żądania. S8

Występują dwa rodzaje ryzyka:

• Wstrzyknięcie treści żądania: ładunek ramki inny niż DATA przesłany przez klienta może zostać przesłany do aplikacji nadrzędnej, zmieniając dane faktycznie odebrane przez backend.
• obejścia limitu rozmiaru: client_max_body_size i inne ograniczenia. Oczekiwane kontrole koncentrują się na ścieżce DATA, a niepoprawnie przekonwertowana treść może ominąć odpowiednią weryfikację.

Typowy scenariusz wyzwalania opisany przez urzędnika ma miejsce, gdy ngx_http_v3_module odbiera żądanie HTTP/3 i przekazuje dalej proxy_request_buffering on. Buforowanie treści żądania proxy jest domyślnie włączone w ngx_http_proxy_module. Dlatego najpierw należy sprawdzić odwrotne proxy, które włącza HTTP/3. Niewłaściwe jest zakładanie, że nie ma warunku wyzwalającego tylko dlatego, że proxy_request_buffering on; nie jest jawnie zapisany. S8S18

Bezpośrednią konsekwencją tej luki jest zmiana integralności żądań zaplecza i granic bezpieczeństwa, która nie jest równoważnym wyrażeniem RCE bezpośrednio wypełnionym w rdzeniu NGINX. Ostateczny wpływ na działalność biznesową zależy od tego, jak te bajty zostaną przeanalizowane i zaufane na początku procesu. S24

2.6 CVE-2026-97629: TLS Rotacja biletów pomija trzecie miejsce na klucz

W konfiguracjach, których to dotyczy, NGINX może automatycznie generować i obracać klucze biletów sesji TLS poprzez pamięć współdzieloną, umożliwiając wielu Worker przetwarzanie tej samej partii biletów.

Odpowiednia logika synchronizacji przydziela 3 szczeliny na klucze dla każdego Worker, a wywołanie zwrotne deszyfrowania również przejdzie przez te szczeliny; ale stara implementacja kopiuje za każdym razem tylko 2 gniazda kluczy z pamięci współdzielonej, co daje nazwę klucza, klucz HMAC i AES trzeciego gniazda. Klucz może pozostać niezainicjowany. Jeśli identyfikator klucza biletu jest zgodny z tym statusem, niezainicjowany materiał klucza może zostać użyty do weryfikacji podpisu i odszyfrowania, tworząc w ten sposób ścieżkę do sfałszowania sesji TLS. S9

Kombinacje wdrożeń obarczone wysokim ryzykiem to zazwyczaj:

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

Najpoważniejszą konsekwencją biznesową tej luki jest to, że w usługach korzystających z uwierzytelniania certyfikatu klienta (mTLS) w ssl_verify_client on; i w inny sposób sfałszowane sesje odzyskiwania mogą ominąć weryfikację certyfikatu klienta. Powodzenie ataku zależy również od niekontrolowanych warunków; witryny, która korzysta wyłącznie ze zwykłego certyfikatu HTTPS po stronie serwera i nie uwierzytelnia się za pomocą certyfikatu klienta, nie należy błędnie określać jako „osoba atakująca może ominąć cały login do witryny”. S9S12

Jest to problem związany ze statusem uwierzytelnienia sesji TLS i nie ma nic wspólnego z tym, czy klucz prywatny TLS serwera został złamany lub czy ma to wpływ na publiczny certyfikat CA root. S24

2.7 Jak zrozumieć DoS, RCE, obejście uwierzytelnienia i znane exploity

• DoS: Błąd pamięci powoduje awarię Worker lub masowe ponowne uruchomienie. To, czy powoduje to ogólną niedostępność, zależy od natężenia ruchu, możliwości ponownego uruchomienia procesów, czasu konserwacji połączenia i architektury o wysokiej dostępności.
• potencjał RCE: Niektóre zapowiedzi wskazują, że istnieje możliwość wykonania kodu w przypadku zamknięcia lub pominięcia ASLR. Nie oznacza to, że ujawniono publiczny łańcuch ataków, który może stabilnie i uniwersalnie wykonywać polecenia. S4
• Żądanie wstrzyknięcia/obejścia uwierzytelnienia: może bezpośrednio zmienić chroniony status firmy lub żądać treści i nie można go zignorować tylko dlatego, że nie uzyskuje bezpośrednio powłoki.
• odkrył próby ataku: CVE-2026-42945 w maju 2026 r. zawiera raporty o działaniach eksploatacyjnych w środowisku naturalnym; nie powinno bezpośrednio wnioskować z tego historycznego faktu, że wszystkie pięć CVE w październiku zostało pomyślnie wykorzystanych na dużą skalę. S23

3. Napraw wersję i wybór poprawki

3.1 NGINX Open Source oficjalna wersja bazowa łatki

gałąź górna	Pierwsza oficjalna wersja obejmująca pięć luk w zabezpieczeniach w październiku	Zalecenia od 2026-10-27
Stable 1.30.x	1.30.6（2026-10-14）	Zainstaluj co najmniej 1.30.6 i sprawdzaj kolejne wersje zabezpieczeń.
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
Wcześniejsza gałąź NGINX Open Source	Nie można tego oceniać wyłącznie na podstawie tego, że „zastosowano stare poprawki luk w zabezpieczeniach”.	Najpierw przeprowadź migrację do utrzymywanej gałęzi; w przeciwnym razie sprzedawca jest zobowiązany do przedstawienia formalnego dowodu wsparcia na podstawie CVE-by-CVE.

Są to wnioski dotyczące wersji kodu źródłowego źródłowego/oficjalnej gałęzi nginx.org i nie należy ich używać do bezpośredniego odrzucania pakietu bezpieczeństwa z przeniesionymi poprawkami dostarczonymi przez dostawcę dystrybucji. Nawet jeśli wartość 1.31.6 jest większa niż 1.30.6, nadal jest niższa niż linia bazowa poprawki głównej gałęzi. S1S2

3.2 Zakres wpływu pięciu CVE na wyższym szczeblu łańcucha dostaw

Poniższe zakresy są wymienione zgodnie z oryginalnym tekstem biuletynu bezpieczeństwa nginx.org i należy je rozumieć w połączeniu z „bieżącą działającą gałęzią” i „rzeczywistą ścieżką konfiguracji”:

CVE	Wersje, których dotyczą tagi nadrzędne	Oficjalnie oznaczona wersja naprawiona
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ lub 1.31.7+, w odpowiednich oddziałach
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	To samo co powyżej
CVE-2026-97205	0.8.11–1.31.6	To samo co powyżej
CVE-2026-95101	1.25.0–1.31.6	To samo co powyżej
CVE-2026-97629	1.23.2–1.31.6	To samo co powyżej

CVE-2026-93479 ma określone ograniczenia wersji wprowadzającej; nie każda stara wersja NGINX jest dotknięta tą regresją. Starsze wersje spoza tych zakresów mogą nadal być dotknięte wcześniejszą luką map związaną z wyrażeniem regularnym CVE-2026-42533. S1

3.3 Ubuntu: backporty dystrybucji (USN-8955-1)

Firma Canonical USN-8955-1 26 października 2026 r. udostępnia aktualizację zabezpieczeń dla czterech kompilacji Ubuntu: S13

Wersja Ubuntu	nginx i ta sama poprawiona wersja pakietu źródłowego	Opis
22.04 LTS	1.18.0-6ubuntu14.22	Jest to backport dostawcy; numer wersji nadrzędnej nadal pokazuje 1.18.0
24.04 LTS	1.24.0-2ubuntu7.19	To samo co powyżej
26.04 LTS	1.28.3-2ubuntu1.12	To samo co powyżej
26.10	1.30.4-7ubuntu1.1	To samo co powyżej

Ogłoszenie zawiera odpowiednie, stałe wersje pakietów homologicznych, takich jak nginx-core, nginx-extras, nginx-full i nginx-light. Nie wyciągaj wniosków na temat tego, czy to naprawić, z części poprzedzającej pokazanej tylko przez nginx -v. takie jak Ubuntu 24.04 i 1.24.0-2ubuntu7.19 zostały poprawione przez tego dostawcę, ale 1.24.0 z jakiegokolwiek źródła nie jest wewnętrznie bezpieczny.

Ubuntu oficjalnie również wyraźnie zaznaczyło, że CVE-2026-95101 dotyczy tylko Ubuntu 26.04 / 26.10, a CVE-2026-97629 dotyczy tylko Ubuntu 24.04 / 26.04 /26.10. Oto własne opakowanie i zakres funkcjonalności Ubuntu, którego nie można bezpośrednio promować w innych dystrybucjach. S13

3.4 Debian: Różnice pomiędzy wersjami należy sprawdzić osobno

Doradztwo Debian DSA-6575-1 (2026-10-21) obejmuje te pięć CVE i identyfikuje stały pakiet nginx dla Debian 13 / trixie jako:

1.26.3-3+deb13u10

Jednak od czasu weryfikacji tego raportu 1.22.1-9+deb12u10 dla Debian 12 / bookworm jest nadal oznaczany jako podatny na ataki przez narzędzie śledzące bezpieczeństwo Debian. Dlatego:

• Debian 13 Wystarczy zaktualizować i zaakceptować zgodnie z DSA-6575-1.
• Debian 12 musi po kolei sprawdzać poprawki bezpieczeństwa dostarczone przez bieżącego moduł śledzący bezpieczeństwo lub dostawcę ELTS; przed potwierdzeniem poprawki w ogłoszeniu nie deklaruj, że wszystkie pięć elementów zostało naprawionych w oparciu o sukces apt upgrade.
• Pakiet źródłowy Debian może zawierać zestaw poprawek niezależny od numeru wersji nginx.org. W przypadku kompilacji niestandardowych należy sprawdzić cały zestaw poprawek pakietu kodu źródłowego. Nie można po prostu skopiować pojedynczego zatwierdzenia z góry i uznać je za zakończone.

Powyższe rozróżnienie opiera się na zapisach śledzenia DSA i CVE. S14S15S16

3.5 NGINX Plus, njs i kontroler wejścia

Produkty/Komponenty	Kluczowe punkty dotyczące wyboru zabezpieczeń i weryfikacji
NGINX Plus (wersja komercyjna)	Proszę zapoznać się z ogłoszeniem i instrukcją aktualizacji oddziału Plus odpowiadającą F5. Najnowsza wersja CR w momencie weryfikacji to PLS.37.2.0.1, a wersja zabezpieczeń LTS to PLS.37.0.7.1; wersji Plus i dołączonego backportu nie można bezpośrednio zastąpić progiem 1.30/1.31 Open Source. S19
njs / ngx_http_js_module	2026-10-14 wypuszcza njs 1.0.2 i naprawia CVE-2026-101019 i CVE-2026-101025; jeśli korzystasz z njs, musisz także sprawdzić kompatybilność modułu z NGINX. S20
F5 NGINX Kontroler wejścia / tkanina bramy	Rdzeń NGINX to powiązany, ale niezależny łańcuch dystrybucji oprogramowania. Napraw odpowiednie luki w zabezpieczeniach za pomocą odpowiednich kontrolerów, obrazów i informacji o wersji. Nie można po prostu zastąpić pliku binarnego NGINX w kapsule.
Kubernetes Społeczność kubernetes/ingress-nginx	Projekt zostanie wycofany z eksploatacji w marcu 2026 r. i nie będzie już zapewniał nowego utrzymania bezpieczeństwa. Powinieneś zaplanować migrację do obsługiwanego kontrolera lub Gateway API, zamiast mylić jego numer wersji z kontrolerem wejścia F5 NGINX. S21

3.6 Który patch właściwie wybrać?

Formularz wdrożenia	Zalecane praktyki	Dowód naprawy
Oficjalny pakiet DEB/RPM nginx.org	Uaktualnij do stałej wersji gałęzi nadrzędnej	nginx -v/-V, źródło pakietu, oficjalny komunikat dotyczący bezpieczeństwa
Oficjalne repozytorium Ubuntu/Debian	Zainstaluj pakiety zabezpieczeń dostawcy	Pełna wersja pakietu + status USN/DSA dostawcy + CVE
RHEL/Alma/Rocky/SUSE/Inne dystrybucje	Aktualizuj zgodnie z określonymi biuletynami bezpieczeństwa dystrybucji i wersjami pakietów	Odpowiedni dostawca CSAF/ogłoszenie, nie można zastosować wersji Ubuntu/Debian
Oficjalne lub niestandardowe obrazy kontenerów	Odbuduj lub pobierz zweryfikowany obraz naprawy i zastępuj go na bieżąco	Podsumowanie obrazu, kompilacja SBOM, identyfikator obrazu uruchomionego pod/kontenera
Samokompilowane NGINX, OpenResty, Tengine lub wersje z poprawkami z modułami innych firm	Nadaj priorytet wykorzystaniu pełnej wersji bezpieczeństwa opiekuna; w razie potrzeby wykonaj sprawdzone backporty poprawek dla docelowego drzewa źródłowego	Pięć poprawek luk w zabezpieczeniach, kompatybilność ABI/modułu, regresja jednostkowa i biznesowa

OpenResty i Tengine to różne systemy zwalniania; tabela ta opisuje jedynie metodę weryfikacji. nie oznacza, że ​​dotyczy to wszystkich jego wersji w tym samym czasie, co standardowy NGINX, ani że poprawka kodu źródłowego nie może być zastosowana bezwarunkowo.

4. Formalny proces naprawy

4.1 Inwentaryzacja rzeczywistych przypadków odbioru ruchu zewnętrznego

Dla każdego wpisu zestaw co najmniej:

• Nazwa domeny, równoważenie obciążenia/CDN/łącze proxy brzegowego, metoda ekspozycji strony początkowej i używany protokół sieciowy.
• Produkty NGINX (Open Source, Plus, Ingress itp.), pełna wersja, źródło repozytorium pakietów, podsumowanie obrazu.
• nginx -V wyświetla moduły budowania i parametry kompilacji; czy istnieją njs, Lua, OpenResty i moduły dynamiczne innych firm.
• Prawdziwie działające master/worker PID, jednostka serwisowa/kontener/kapsuła, replika i węzeł Worker.
• Rzeczywiste efektywne konfiguracje http/stream, server, location, include.
• Czy włączyć HTTP/3, mTLS, SSI/AIO, dynamiczną ścieżkę dziennika, złożone map i przechwytywanie wyrażeń regularnych.

Nie sprawdzaj tylko domyślnego /etc/nginx/nginx.conf. Środowisko produkcyjne często ładuje wiele lokalizacji, TLS i konfiguracje modułów do include. Może również istnieć wiele ścieżek instalacji NGINX lub wiele warstw proxy.

4.2 Sprawdź informacje o wersji i kompilacji

# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1

# Linux：查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

# Debian / Ubuntu：查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null

# RPM 系：以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'

nginx -V zgłasza kompilację pliku binarnego znalezionego w ścieżce wiersza poleceń; nie dowodzi to, że załadował go działający worker. nginx -v może pomijać sufiks pełnego pakietu dystrybucji, dlatego sprawdź także menedżera pakietów lub zapisy łańcucha dostaw.

4.3 Wyeksportuj efektywną konfigurację i wykonaj pierwszą rundę sprawdzania statycznego

nginx -T przetestuje konfigurację i zrzuci scaloną konfigurację. Dane wyjściowe mogą zawierać poufne informacje, takie jak dane uwierzytelniające, ścieżki kluczy, wewnętrzne nazwy hostów itp. Zaleca się zapisanie kontrolowanego terminala z uprawnieniami root i uprawnieniami do plików prywatnych oraz nie publikowanie oryginalnych plików w publicznych zleceniach pracy:

sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'

sudo grep -nE \
  'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
  /root/nginx-effective.conf

To tylko lokalizator ścieżki kandydatów, a nie niezawodne narzędzie do automatycznego określania CVE:

1. grep nie może określić, czy zmienne znajdują się w tym samym location lub w tym samym łańcuchu oceny żądań, ani nie może wywnioskować związku dziedziczenia konfiguracji.
2. proxy_request_buffering on, niektóre konfiguracje pamięci podręcznej i biletów mają wartości domyślne i niezapisanie odpowiednich instrukcji nie oznacza, że ryzyko zniknie.
3. Konfiguracje wygenerowane przez odwrotne proxy, CDN, przyczepy kontenerowe lub kontrolery mogą różnić się od ręcznie sprawdzanych plików.
4. Może zaistnieć potrzeba potwierdzenia właściwości NGINX Plus i modułów dynamicznych przy użyciu odpowiednich oficjalnych narzędzi zarządzania.

4.4 Wdrażaj poprawkę za pośrednictwem zaufanych kanałów

Debian/Ubuntu (oficjalne repozytorium dystrybucji):

sudo apt-get update
apt-cache policy nginx

# 升级发行版仓库中已经安装的 NGINX 及相关包；
# 先确认 Candidate 属于修复版本，再执行升级。
sudo apt-get install --only-upgrade nginx

# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null

Ten zestaw poleceń nie może wygenerować z powietrza poprawek bezpieczeństwa, które nie są jeszcze dostępne. Zwłaszcza w przypadku Debian 12, jeśli zaktualizowany pakiet nadal jest uznawany za podatny na ataki przez system śledzenia bezpieczeństwa, wymagana jest dodatkowa naprawa dostawcy, izolacja lub migracja. S13S14S15

Oficjalny pakiet nginx.org:

# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx

Jeśli używasz samodzielnie skompilowanych OpenResty, Tengine lub NGINX Plus, użyj wersji poprawki obsługiwanej przez odpowiedniego opiekuna i nie mieszaj nginx.org, pakietów dystrybucyjnych i repozytoriów stron trzecich. Należy zachować oryginalne pliki binarne/obrazy, konfiguracje, podpisy i manifesty wdrożenia wycofania.

Kontenery/Kubernetes: zaktualizuj niezmienny obraz, zapisz jego podsumowanie i zastąp wszystkie stare repliki wdrażaniem etapowym. kubectl rollout status potwierdza jedynie, że kontroler wdrażania zakończył działanie; weryfikuj także podsumowania obrazów, routing danych przychodzących i niezdrowe repliki.

4.5 Sprawdź konfigurację i wymień stary Worker

sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

Nie traktuj nginx -s reload jako dowodu, że uruchomiony jest nowy plik binarny: zwykłe przeładowanie konfiguracji pozwala staremu master na uruchomienie nowych procesów roboczych bez wymiany pliku wykonywalnego. NGINX obsługuje dedykowaną procedurę aktualizacji plików binarnych online, ale wymaga dodatkowych kroków i weryfikacji. Bez ustalonej procedury użyj przełącznika ruchu o wysokiej dostępności, a następnie uruchom ponownie usługę lub wprowadź kontenery zastępcze. S22

Jeśli zarządzasz NGINX poprzez gniazdo systemd, skrypt wejściowy kontenera lub wiele instalacji, powinieneś sprawdzić rzeczywisty cel uruchomienia i ścieżkę procesu, zamiast bezpośrednio zakładać, że systemctl restart nginx obejmuje wszystkie instancje.

4.6 Zaakceptuj i wykonaj regresję biznesową z prawdziwego wejścia zewnętrznego

Zaleca się wykonanie co najmniej:

• Czy normalne strony HTTPS, przepisane trasy, zasoby statyczne i strony mapowania alias są prawidłowe?
• Czy zwykła dystrybucja map, zmienna ścieżka root, ścieżka dziennika dostępu, SNI/routing certyfikatu i proxy Stream są prawidłowe.
• Czy normalne przesyłanie, przesyłanie fragmentaryczne, żądania API i limity wolumenu przesyłania danych dla HTTP/3 (jeśli są włączone) są nadal zgodne z oczekiwaniami.
• mTLS: Prawidłowe żądania certyfikatów powinny zakończyć się pomyślnie; brakujące, wygasłe lub nieautoryzowane certyfikaty powinny być nadal odrzucane, a wznowienie/ponowne połączenie TLS nie powinno przypadkowo zmienić uprawnień.
• Czy dostęp do strony SSI i asynchroniczny plik jest normalny; dziennik błędów nie wykazuje żadnych nieprawidłowych żądań odwołań do pamięci ani powtarzających się awarii Worker.
• Po przełączeniu ruchu proces starej wersji i stara replika obrazu powinny zostać zakończone.

Testowanie należy przeprowadzić w środowisku własnym lub autoryzowanym. Zwykły test dymu na żądanie nie może sam udowodnić, że luka w pamięci została naprawiona; ostatecznie poprawiona wersja dostawcy, poprawka do kodu źródłowego i test środowiska wykonawczego muszą zostać wspólnie zaakceptowane do akceptacji.

5. Środki łagodzące, gdy natychmiastowa aktualizacja nie jest możliwa

Ta sekcja dotyczy opcji zmniejszenia ryzyka, a nie wymiany łatki. Należy utworzyć kopię zapasową wszystkich tymczasowych zmian konfiguracji, wykonać nginx -t, udostępnić partiami i szybko wycofać, jeśli to konieczne. S3S4

5.1 Kontroluj priorytet ruchu w oparciu o ekspozycję zewnętrzną

Nadaj priorytet ograniczeniu powierzchni ataku usług, których nie można zaktualizować na czas: na powierzchni zarządzania i wewnętrznie API Dodaj kontrolę dostępu do zaufanego źródła, izolację sieci nadrzędnej lub krótkotrwały tryb offline; dodawaj połączenia, treść żądania i limity szybkości do wejść wysokiego ryzyka; upewnij się, że uwierzytelnianie źródła następuje w związanym z wpisem NGINX przed łańcuchem przetwarzania żądań. Należy zauważyć, że większość samych luk znajduje się w NGINX. Wewnątrz płaszczyzny danych tradycyjne reguły WAF mogą nie określać dokładnie warunków wyzwalania konfiguracji niestandardowej.

5.2 alias / rewrite: unikaj oceniania $request_filename po przepisaniu

Zaleca się sprawdzenie i regulację:

• Staraj się nie wykonywać rewrite, który zmieni URI w tym samym czasie, co location przy użyciu alias.
• Unikaj używania $request_filename, gdy URI został przepisany, ale prawidłowe dopasowanie pozycji nie zostało jeszcze zakończone.
• Sprawdź pośrednie odniesienia do zmiennych w return, set, if, add_header, format dziennika dostępu i dołącz pliki.
• Używaj czystego root/try_files/niezależnego location, jeśli pozwala na to biznes, ale zmieniaj tylko alias na root. Może także zmienić semantykę ścieżki pliku, która musi być sprawdzana jedna po drugiej.

Nie kopiuj bezpośrednio popularnego „szablonu bezpiecznego przepisywania” w Internecie, aby zastąpić istniejącą konfigurację. Różne prefiksy location i cele przepisywania powodują łączenie ścieżek o zupełnie innym znaczeniu. S5

5.3 map/Regex: Zmniejsz mieszanie zmiennych stanów przechwytywania

Zaleca się nadanie priorytetu nazwanym przechwyceniom i ograniczenie zakresu ich propagacji, zamiast pozwalać na ponowne wykorzystanie anonimowych przechwytów, takich jak $1, w różnych ścieżkach oceny wyrażeń regularnych w czasie. Na przykład:

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

Ten fragment demonstruje jedynie łatwiejszą do kontrolowania strukturę własności zmiennej; nie oznacza, że ​​udowodniono, że niezależnie eliminuje wszystkie ścieżki wyzwalacza CVE-2026-93479. W szczególności należy sprawdzić, czy do zmiennych przechwytywania odwołują się z wyprzedzeniem inne root lub log_format oraz czy istnieją volatile, ścieżki dynamiczne i współzależne łańcuchy oceny. F5/CERT zaleca stosowanie nazwanego przechwytywania i ograniczenie zakresu stosowania do odpowiedniej regularnej konfiguracji dopasowującej jako krótkoterminową ulgę. S3S6

5.4 AIO + SSI: Wyłącz niepotrzebne kombinacje funkcji

W przypadku serwerów/ścieżek, które nie wymagają SSI ani asynchronicznego wejścia/wyjścia pliku, użyj:

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

Z punktu widzenia warunków wyzwalających podatność, zamknięcie jednego z nich zwykle wystarcza, aby usunąć określony opisany łańcuch; zamykanie w tym samym czasie ma zastosowanie tylko w scenariuszach, w których firma nie polega na tej możliwości. Sprawdź include virtual, podżądania, pamięć podręczną i zachowanie puli wątków; gdy obciążenie zwrotnego proxy jest wysokie, zamknięcie AIO może zmienić opóźnienie i wydajność we/wy. S7

5.5 HTTP/3 Poproś o zastrzyk do ciała: w razie potrzeby tymczasowo zamknij wejście

Wyłącz nasłuch quic obejmujący HTTP/3, anuluj nagłówek odpowiedzi Alt-Svc, który ogłasza HTTP/3 i sprawdź, czy warstwa brzegowa/system równoważenia obciążenia nadal wysyła żądania QUIC bezpośrednio do nienaprawionego NGINX:

# 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen
server {
    listen 443 ssl;  # 保留 HTTPS/TCP 入口
    # 对支持新版语法的构建，可在此使用 http2 on;
    # 删除原有的 listen 443 quic reuseport;
    # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项）
    # 其余证书、server_name、location 等配置保持不变
}

Powyższe stanowi jedynie opis różnicy zmian, a nie pełną konfigurację serwera, którą można włączyć indywidualnie. Składnia ustawień HTTP/2 jest powiązana z wersją NGINX; jeśli chcesz zachować HTTP/2, powinieneś użyć http2 on; lub istniejącej prawidłowej składni zgodnie z odpowiednią wersją i sprawdzić w nginx -t. należy połączyć z istniejącą konfiguracją serwera przed wdrożeniem, zamiast zastępować całą sekcję tą sekcją. sprawdza również zaporę UDP 443, lokalizację zakończenia HTTP/3 i rezerwową ścieżkę klienta CDN/front proxy.

Innym rodzajem krótkoterminowego rozwiązania jest użycie proxy_request_buffering off; na dotkniętej ścieżce proxy, ale zmieni to zachowanie przesyłania strumieniowego treści żądania nadrzędnego, ponownych prób niepowodzenia i niektórych przepływów pracy przesyłania; można używać dopiero po wystarczających testach i potwierdzeniu, że dyrektywa trafia do ścieżki proxy HTTP/3, której dotyczy problem. S8S18

5.6 TLS Bilet sesji: Ochrona priorytetowa mTLS Granica uwierzytelnienia

Jeśli aktualizacja nie jest możliwa, a instancja opiera się na współdzielonej pamięci podręcznej sesji + automatycznej rotacji kluczy biletów, oceń:

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

Może to wyłączyć mechanizm biletu sesji TLS, usuwając w ten sposób ścieżkę fałszowania biletu opisaną w tej luce; może to jednak mieć wpływ na wydajność wznawiania sesji. Nie można po prostu wyłączyć weryfikacji certyfikatu klienta mTLS, aby „uniknąć luk”, ponieważ spowoduje to bezpośrednie usunięcie oryginalnej granicy uwierzytelniania. S9S12

Jawne pliki ssl_session_ticket_key i bezpieczna rotacja mogą być również wykorzystywane przez profesjonalne procesy zarządzania TLS w celu obejścia automatycznie generowanych warunków, ale opieka nad kluczami, dystrybucja pełnych węzłów, rotacja i stare cykle życia biletów muszą być dokładnie kontrolowane. Nie zaleca się kodowania długoterminowego klucza wielokrotnego użytku w zwykłej konfiguracji sieciowej lub skryptach na wypadek tymczasowych sytuacji awaryjnych. Usługi krytyczne korzystające z mTLS należy dodatkowo monitorować pod kątem zachowania wznawiania sesji TLS i odrzucania żądań bez ważnego certyfikatu klienta. S12

5.7 Rola systemu operacyjnego i ochrony granic

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR, pracownicy inni niż root, kontenerowe systemy plików tylko do odczytu, minimalne uprawnienia do plików i izolacja sieci mogą zmniejszyć wpływ potencjalnego RCE. ASLR nie naprawia przepełnienia sterty ani UAF i nie może zagwarantować, że procesy robocze nie ulegną awarii. WAF, limity szybkości i limity rozmiaru treści żądania nie naprawiają synchronizacji klucza biletu TLS. S4

5.8 Powszechne nieporozumienie: Te operacje nie wystarczą do zakończenia naprawy

Wspólne operacje	Dlaczego to jest niewystarczające?
„nginx -v wygląda na stosunkowo nowy”	Gałąź, do której należy, pełna przeniesiona wersja pakietu i proces online nie są sprawdzane.
„Tylko jeden z intranetów został zaktualizowany”	Stara instancja Worker/stary kontener/stara instancja źródłowa CDN nadal otrzymuje żądania
„Witryna nie używa tagów PHP/dynamicznych”	Wada występuje w ścieżce rdzenia NGINX lub analizie protokołu i nie opiera się na wykonaniu PHP.
„Wystarczy otworzyć WAF/Cloudflare”	Nie można udowodnić, że WAF blokuje wszystkie błędy pamięci zależne od konfiguracji NGINX lub błędy wznawiania TLS
„Już otwarte ASLR”	Po prostu skorzystanie z łagodzenia trudności; DoS z wtryskiem żądania jest nadal możliwy
„HTTP/3 nie jest dostępny w sieci publicznej, więc nie ma w ogóle potrzeby aktualizacji”	Pozostałe cztery CVE nadal wymagają niezależnej oceny; i mogą istnieć bezpośrednie powiązania z ukrytymi źródłami
„Naprawiono lipcową lukę w zabezpieczeniach map”	Październik CVE-2026-93479 wiąże się z kolejnymi problemami związanymi z regresją oceny skryptu
„Wyłączenie buforowania rozwiązuje wszystkie problemy”	Dotyczy tylko niektórych scenariuszy pamięci podręcznej TLS lub AIO i nie obejmuje aliasów, skryptów ani HTTP/3

6. Oficjalne pomysły na wdrożenie łatki i punkty kontrolne

W tej sekcji opisano poprawki NGINX z października 2026 r. Fragmenty ilustrują reprezentatywne zmiany do przeglądu poprawek; nie są to kompletne, niezależnie kompilowane poprawki. W przypadku kompilacji niestandardowych przejrzyj pełne zatwierdzenia, otaczający kod i testy i preferuj pełną obsługiwaną wersję. S5S6S7S8S9

6.1 CVE-2026-15176: URI został przepisany w celu uwzględnienia warunków odrzucenia mapowania ścieżki alias

Zatwierdzenie nadrzędne zmodyfikowało ngx_http_map_uri_to_path() w src/http/ngx_http_core_module.c:

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

skupienie się na przeglądzie: Nie można kontynuować obliczania ścieżki systemu plików, gdy URI uległ zmianie, ale odpowiednia semantyka lokalizacji alias nie jest już niezawodna. Jest to udoskonalenie ograniczenia stanu wstępnego. Nie jest to proste sprawdzenie, czy żądanie URI zawiera niedozwolone znaki. S5

6.2 CVE-2026-93479: Poprawnie rozróżnij długość danych wyjściowych od długości zarezerwowanej

Zatwierdzenie nadrzędne aktualizuje jednocześnie src/http/ngx_http_script.c i src/stream/ngx_stream_script.c. Podstawową intencję można podsumować następująco:

- n = len;
+ n = 0;
  /* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);

Tutaj pool jest ilustracyjną nazwą parametru: rzeczywiste wyrażenia alokacji HTTP i Stream różnią się. Zmiana najpierw oblicza długość wyjściową skryptu, a następnie dodaje zarezerwowaną długość do ostatecznej alokacji, tak aby dane wyjściowe nie nadpisywały zarezerwowanego miejsca. S6

Podczas audytu i backportingu należy uwzględnić również odpowiedni ewaluator HTTP/Stream; jedynie sprawdzenie pliku składni konfiguracyjnej map nie może udowodnić, że defekt został naprawiony.

6.3 CVE-2026-97205: Ustaw próg bezpieczeństwa dla 8-bitowej liczby operacji asynchronicznych

Upstream dodano w src/http/ngx_http_request.h:

#define NGX_HTTP_MAX_BLOCKED 250

I dodaj podobne wpisy do asynchronicznego odczytu plików, oczekiwania na pamięć podręczną, filtrowania danych wyjściowych i operacji wątków:

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

skupienie się na przeglądzie: Należy uwzględnić wszystkie rzeczywiste ścieżki kodu, które dodadzą r->main->blocked. Nie można po prostu zapisać stałej progowej w pliku nagłówkowym. Backport musi także sprawdzić pełną koordynację synchronicznego powrotu, asynchronicznego wywołania zwrotnego i powrotu po błędzie, aby upewnić się, że zakleszczenie lub wyciek referencji nie będą spowodowane bezpośrednim odrzuceniem zadań. S7

6.4 CVE-2026-95101: Zachowaj status skip oddzielnie dla nieznanych ramek

Upstream dodaje pole skip do struktury statusu parsera HTTP/3 i przeprowadza separację statusów:

if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
    st->skip = st->length;
    st->length = 0;
    st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);

Kluczem nie jest „wyłączenie nieznanych ramek HTTP/3”, ale zapewnienie, że przy wielokrotnych odczytach liczba pominiętych bajtów i długość ładunku DATA są zawsze zarządzane przez niezależne stany. Recenzje powinny skupiać się na nieznanym dzieleniu buforów między buforami ramek i ostatecznej spójności client_max_body_size. S8

6.5 CVE-2026-97629: Zsynchronizuj cały układ gniazd kluczy TLS

Zmiany poprzedzające znajdują się pod adresem src/event/ngx_event_openssl.c:

  ngx_memcpy(keys->elts, cache->ticket_keys,
-            2 * sizeof(ngx_ssl_ticket_key_t));
+            keys->nelts * sizeof(ngx_ssl_ticket_key_t));

Oryginalny obraz zawierał trzy kluczowe miejsca, ale skopiowano tylko dwa pierwsze. Zamiast tego należy przeprowadzić synchronizację w oparciu o rzeczywistą liczbę elementów tablicy, aby mieć pewność, że zestaw kluczy głosowania Worker jest spójny z pamięcią współdzieloną. Podczas przeglądu należy również upewnić się, że alokacja tablicy, inicjalizacja, wspólna blokada i logika rotacji są spójne, a nie tylko raz sprawdzić modyfikację długości memcpy. S9

6.6 Dlaczego nie zaleca się stosowania wyłącznie rozproszonych fragmentów łat?

Te pięć modyfikacji obejmuje odpowiednio src/http, src/stream, src/http/v3 i src/event, a starsze wersje mogą mieć zabezpieczenia i nieoficjalne rozszerzenia. Backporting powinien tworzyć następującą macierz kontrolną:

Sprawdź obiekt	Co należy potwierdzić
źródło poprawki	Oficjalne zgłoszenie, zgodna wersja docelowa, pełna weryfikacja łatki i podpisu
Oryginalny zestaw poprawek	Nie koliduje z historycznymi modyfikacjami, takimi jak CVE-2026-42533, backport dystrybucji itp.
ścieżka kodu	Skrypt HTTP + Stream, AIO/wątek, HTTP/3, OpenSSL Wszystkie bilety są objęte gwarancją
Skompilowany kompatybilny	OpenSSL, PCRE, moduł ABI, moduł dynamiczny i zależności łącza są spójne
regresja funkcjonalna	Przepisanie alias, dziennik dynamiczny, SSI/AIO, przesłanie HTTP/3, wznowienie sesji mTLS
czas wykonania	Wszystkie Worker/Pody obsługują nowe zweryfikowane kompilacje, nie pozostają żadne starsze obrazy

W przypadku zespołów, które utrzymują własne wydania, zaleca się przechowywanie możliwych do sprawdzenia identyfikatorów poprawek, wersji pakietów, dzienników kompilacji i raportów regresji dla każdego CVE; w przypadku zwykłej obsługi i konserwacji najbezpieczniejszym rozwiązaniem jest zainstalowanie kompletnych aktualizacji zabezpieczeń dostawcy.

7. Wycofywanie się podatności historycznych, stare gałęzie i inne produkty

7.1 NGINX Podstawowa luka warta jednoczesnego potwierdzenia w okresie od maja do września 2026 r.

Nowy problem z października dotyczy nie tylko wielu instancji NGINX, które nie były aktualizowane przez długi czas. Poniżej przedstawiono reprezentatywne węzły naprawcze w najbliższej przyszłości: S1S2

CVE	Pierwsza wersja poprawki	Kluczowe ryzyka i warunki wymagające audytu
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0, 13 maja	rewrite Anonimowe przechwytywanie i zastępowanie wyrażeń regularnych powoduje przepełnienie sterty, potencjalne RCE; istnieją publiczne doniesienia o próbach ataków na wolności
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1, 22 maja	Nakładające się przechwytywanie wyrażeń regularnych i szacowanie długości w rewrite prowadzą do przepełnienia
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2, 17 czerwca	HTTP/2 Specyficzna konfiguracja dla upstream lub gRPC, duży warunek nagłówka żądania powoduje przepełnienie bufora
CVE-2026-42530	Mainline 1.31.2, 17 czerwca	HTTP/3 bez użycia; oficjalny znak objęty zakresem 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3, 15 lipca	map + ocena zmiennej przechwytującej wyrażenie regularne powoduje przepełnienie sterty, a kolejne poprawki mają korelację regresyjną z CVE-2026-93479 w październiku
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3, 15 lipca	ngx_http_slice_module Wyciek zawartości pamięci w określonych warunkach aktualizacji zmiennych i pamięci podręcznej
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3, 15 lipca	SSI jest powiązany z UAF; to nie ta sama przyczyna root, co październikowa luka AIO polegająca na zliczaniu
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6, 15 września	Ograniczone przepełnienie sterty HTTP/3 + specyficzna kombinacja wersji OpenSSL, objawiające się głównie awarią/ograniczonym uszkodzeniem pamięci

Inne luki w zabezpieczeniach, takie jak NGINX Core, HTTP/2, charset i SMTP ogłoszone w 2026 r. również powinny zostać zbadane zgodnie z oficjalnymi biuletynami bezpieczeństwa; tabela ta celowo skupia się na typowych zdarzeniach, które są najbardziej istotne dla bieżących wdrożeń odwrotnego proxy NGINX dostępnego publicznie i mają wpływ na bezpieczeństwo pamięci lub integralność żądań. to nie wszystkie CVE w 2026 r. Lista. S1

Dlaczego warto zwrócić szczególną uwagę na CVE-2026-42945

Agencje rządowe opublikowały biuletyny bezpieczeństwa, które w maju odnotowują działania związane z wykorzystywaniem oprogramowania w środowisku naturalnym oraz informacje o publicznym kodzie wykorzystania tej luki rewrite. Dlatego w przypadku instancji, które nie były łatane przez długi czas od maja do chwili obecnej i mają otwarte złożone przepisywania wyrażeń regularnych w sieci publicznej, oprócz zakończenia naprawy, należy dodatkowo sprawdzić nieprawidłową awarię Worker, logi dostępu i podejrzane zmiany w tym czasie. S23

„Nastąpiła próba ataku” nie oznacza automatycznie, że atakujący niezawodnie wykonał polecenia wobec każdego celu; gdy w grę wchodzi reakcja na incydenty, wskaźniki naruszeń i awarie procesów należy badać oddzielnie od prawdziwych dowodów eskalacji uprawnień lub utrzymywania się.

7.2 Naprawa dla starszych wersji i backportów dystrybucji

NGINX Różne gałęzie mają własne cykle wsparcia i różne czasy wprowadzenia podatności. Pięć nowych poprawek nie może zostać wdrożonych we wszystkich wczesnych drzewach źródłowych bez sprawdzenia.

scena	Zalecana strategia
Wydana wersja ogłosiła pełne poprawki bezpieczeństwa	Korzystaj z pakietów dostawców i dokumentuj pełne wersje pakietów; unikaj zastępowania niekompatybilnymi, gołymi plikami binarnymi nadrzędnymi
Debian 12 i inne wersje, których dotyczy problem, które nie są jeszcze objęte wszystkimi CVE w tej partii	Przesyłaj zlecenia pracy związane z ryzykiem, ograniczaj narażenie zewnętrzne i sprawdzaj status dostawcy/ELTS; w razie potrzeby migruj lub korzystaj z weryfikowalnego łańcucha wydań konserwacyjnych
Historyczne gałęzie, które zakończyły wsparcie na rynku wyższego szczebla	Nadaj priorytet migracji do obsługiwanych wersji; jeśli konieczne jest krótkotrwałe backportowanie, opiekunowie ocenią zależności i zgodność poprawek oraz napiszą pełne testy.
W zestawie widelec NGINX (OpenResty, Tengine, dostosowana bramka)	Najpierw ustal, czy uwzględniono odpowiednią ścieżkę kodu, a następnie użyj instrukcji bezpieczeństwa opiekuna forka. Nie może być bezpośrednio odpowiednikiem wersji wcześniejszej.
Poprawki bezpieczeństwa prowadzą do zmian w funkcjonalności biznesowej	Stosuj wdrożenia etapowe, przełączanie ruchu między wersjami i dostosowywanie konfiguracji; przywracanie nieustalonej wersji sieci publicznej bez izolacji jest niewłaściwe.

7.3 Oddzielna naprawa dla njs, Ingress i NGINX Core

• njs: Oprócz głównego programu NGINX należy sprawdzić także wersję samego modułu JavaScript NGINX. njs 1.0.2 rozwiązuje problem wyczerpania pamięci analizatora XML z października 2026 r. i niespójności podczas sprawdzania poprawności XML z atrybutami odwołań do encji. W przypadku wdrożeń związanych z weryfikacją podpisu XML przy użyciu nginx-saml, należy dodatkowo przeczytać oficjalne instrukcje njs dotyczące scenariuszy wtyczek. S20
• F5 NGINX Plus / NGINX Kontroler ruchu przychodzącego: Dodatkowo, kontroler i Gateway Fabric mogą mieć dodatkowe biuletyny bezpieczeństwa, różne wersje opakowań i unikalne luki w zabezpieczeniach. Aktualizacja jednej warstwy nie oznacza automatycznej aktualizacji innej warstwy. S19
• Kubernetes Społeczność ingress-nginx: Urzędnicy Kubernetes ogłosili już, że konserwacja sterownika zakończyła się w marcu 2026 roku, a jego magazynu nie można pomylić ze sterownikiem F5. Firmy, których to dotyczy, powinny zaplanować płynną migrację i zweryfikować adnotacje Ingress oraz różnice semantyczne w Gateway API, zamiast czekać na nową wersję zabezpieczeń. S21

8. Kryteria odbioru i kontrole następcze

Zaleca się stosowanie poniższej listy jako warunków akceptacji zleceń zmian:

Projekt	Standardy kwalifikacji	Dowody, które można zachować
Pokrycie zasobów i portalu	Zinwentaryzowano wszystkie instancje zewnętrzne i podłączone bezpośrednio, które mogą ominąć CDN.	Nazwa domeny, LB, IP, lista podów/kontenerów
Źródło pakietu i zakres naprawy	Użyj potwierdzonych wersji, które obejmują wszystkie obowiązujące CVE	Poradnik bezpieczeństwa nadrzędnego, USN/DSA, wersja pakietu, podsumowanie obrazu
stare wyjścia procesów	Wszystkie stare master/worker/kontenery zostały wymienione	PID/czas rozpoczęcia, stan wdrożenia, działający obraz
Audyt konfiguracji	Kombinacje wysokiego ryzyka zostały wyeliminowane lub objęte łatkami, a powiązania dziedziczenia zostały zweryfikowane	zredagowane podsumowanie i zapis audytu nginx -T
TLS/mTLS	Zaufane certyfikaty przechodzą; nieważne lub brakujące certyfikaty są odrzucane; wznowienie sesji nie omija uwierzytelnienia	Negatywny/pozytywny test autoryzacyjny, kontrolowane wyniki testu TLS
Treść żądania HTTP/3	Włącz ścieżkę naprawioną; Treść żądania nadrzędnego i ograniczanie przepustowości działają poprawnie	HTTP/3, przesyłanie proxy, test regresji limitu woluminu
SSI/AIO	Funkcja spełnia wymagania, Worker nie wykazuje nieprawidłowego przerwania	Monitorowanie regresji biznesowej, awarii i błędów
Monitorowanie pracy i konserwacji	Brak oczywistego wyjątku 5xx, SIGSEGV, proces kończy się wielokrotnie	Wskaźniki serwisowe i logi przed i po zmianach
Strategia wycofania	Jeśli konieczne jest wycofanie zmian, najpierw ogranicz ekspozycję i zachowaj granice bezpieczeństwa	Zlecenia zmian, przepływy awaryjne i plany kwarantanny
kolejny cykl życia	Określ subskrypcje biuletynów bezpieczeństwa, częstotliwość aktualizacji kontenerów i plany migracji oddziałów	Aktualizuj księgę, osobę odpowiedzialną i datę następnego audytu

8.1 Na czym należy się skupić w logach i statusie działania?

Rozwiązywanie problemów z nieprawidłowościami na serwerach, które były narażone przez długi czas worker process exited on signal 、 SIGSEGV , skokami liczby niepowodzeń żądań, nieprawidłową agregacją dostępu do źródła, nieoczekiwanym TLS Wznowienie sesji/powodzenie uwierzytelnienia i nietypowe zachowanie treści żądania zaplecza. Wskaźniki te można wykorzystać jedynie jako wskazówki dochodzeniowe i nie stanowią one wystarczającego dowodu bezpośrednio potwierdzającego wykorzystanie określonego CVE. ;Brak odpowiednich logów nie jest dowodem na to, że nie doszło do ataku.

8.2 Zalecane sformułowanie końcowego wniosku dotyczącego ryzyka

Protokół odbioru dla środowiska produkcyjnego powinien zawierać następujące precyzyjne wyrażenie:

Zidentyfikowano wejście do usługi zewnętrznej NGINX i źródło pakietu oprogramowania. Wszystkie odpowiednie instancje zostały zaktualizowane do oficjalnej wersji zabezpieczeń lub ukończono backport potwierdzony przez dostawcę wersji; stare Worker i stare pojemniki zostały wymienione. Treść żądania alias/rewrite/map, AIO/SSI, HTTP/3 i konfiguracje związane z biletem sesji TLS/mTLS zostały poddane audytowi i przeszły testy regresyjne funkcjonalne, uwierzytelniające i integralności żądań. W przypadku instancji, które nie ukończyły jeszcze aktualizacji, należy dodatkowo zarejestrować obszary narażenia, środki kompensacyjne, osoby odpowiedzialne i terminy zakończenia.

Jeżeli łatka dla Debian 12 lub innych wydań jest nadal niekompletna, nie należy oceniać całego formularza akceptacji jako „wypełnionego”; nierozwiązany CVE, należy wyraźnie zapisać, czy istnieje odpowiednia konfiguracja wyzwalacza, status izolacji i ostateczna trasa aktualizacji.

---

Dodatek: Cytowane źródła i linki

Opis: Numery [Sx] w tekście jednakowo odpowiadają tej sekcji. Poniżej priorytetowo traktowane są ogłoszenia dotyczące bezpieczeństwa projektu poprzedzającego, zatwierdzenia kodu, ogłoszenia dostawcy i informacje agencji bezpieczeństwa narodowego. Ważność podanych luk jest opisana zgodnie z kryteriami ratingowymi każdej organizacji wydającej; data weryfikacji danych to 27 października 2026 roku.

S1 — NGINX Open Source Oficjalny biuletyn bezpieczeństwa

• https://nginx.org/en/security_advisories.html

Zawiera starsze wersje, których dotyczy problem, gałęzie poprawek i oficjalne poziomy ważności pięciu październikowych CVE, a także historyczne luki w zabezpieczeniach do 2026 roku.

S2 — rekord wydania oficjalnej wersji NGINX

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

Potwierdź 1.30.6 / 1.31.7 z 2026-10-14, 1.31.8 z 2026-10-21 i najważniejsze etapy wydania zabezpieczeń od maja do września.

S3 – Singapurska Agencja Bezpieczeństwa Cybernetycznego: F5 NGINX Trzy krytyczne luki

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

Opis wyników CVSS v4.0 9.2, wymagane warunki konfiguracji i tymczasowe zalecenia dotyczące łagodzenia skutków dla CVE-2026-15176, CVE-2026-93479 i CVE-2026-97205.

S4 – NHS Anglia: F5 NGINX Zalecenie dotyczące wysokiego ryzyka

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

Opisuje wpływ DoS / potencjalnego RCE na problemy związane z bezpieczeństwem pamięci i ograniczenia, takie jak wyłączenie lub obejście ASLR.

S5 — Oficjalne zatwierdzenie źródła: CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

Odpowiada kontroli stanu alias i r->uri_changed w ngx_http_map_uri_to_path().

S6 — Oficjalne zatwierdzenie źródła: CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

Odpowiada długości skryptu HTTP/Stream i logice alokacji zarezerwowanego bufora.

S7 — Oficjalne zatwierdzenie źródła: CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

Odpowiada progowi zliczania r->main->blocked NGX_HTTP_MAX_BLOCKED 250 i asynchronicznemu zwrotowi ścieżki.

S8 — Oficjalne zatwierdzenie źródła: CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

Separacja stanu odpowiadająca nieznanej długości pozostałej ramki HTTP/3 i długości treści żądania DATA.

S9 — Oficjalne zatwierdzenie źródła: CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

Odpowiada wszystkim gniazdom kluczy podczas synchronizacji TLS Rotacja biletów sesji.

S10 — F5: CVE-2026-15176 Ogłoszenie dostawcy

• https://my.f5.com/manage/s/article/K000162416

Lista czynników wyzwalających, takich jak alias, rewrite, $request_filename i dzienniki dostępu.

S11 — F5: CVE-2026-93479 Ogłoszenie dostawcy

• https://my.f5.com/manage/s/article/K000162607

Wyświetl listę przechwyconych wyrażeń regularnych mapy, ścieżkę root i zarejestruj warunki oceny zmiennych.

S12 — NGINX oficjalna dokumentacja modułu TLS/SSL

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

Opis ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key i uwierzytelnianie certyfikatu klienta oraz inne instrukcje.

S13 — Doradztwo dotyczące bezpieczeństwa: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

Zapewnij kompletny pakiet oprogramowania, stałą wersję i zakres dystrybucji Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — Doradztwo dotyczące bezpieczeństwa: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

Potwierdź pakiet poprawek bezpieczeństwa 1.26.3-3+deb13u10 dla Debian 13 / trixie i zapisz powiązanie backportu dla CVE-2026-93479.

S15 — Śledzenie podatności: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

Służy do weryfikacji statusu poprawki dystrybucyjnej Debian 12 / bookworm i Debian 13 / trixie. Ten stan może się zmienić wraz z przyszłymi aktualizacjami zabezpieczeń.

S16 — Śledzenie podatności: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

Dodatkowe potwierdzenie stanu bezpieczeństwa luki HTTP/3 na różnych gałęziach Debian.

S17 — Doradztwo dotyczące bezpieczeństwa: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

Dodatkowe zrozumienie korelacji między październikową luką w postaci regresji a poprawką z lipca CVE-2026-42533.

S18 — Oficjalny dokument modułu odwrotnego proxy NGINX

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

Zapytaj o semantykę i wartości domyślne konfiguracji, takich jak proxy_request_buffering, client_max_body_size, alias, aio itp.

S19 — NGINX Plus Oficjalne informacje o wydaniu

• https://docs.nginx.com/nginx/releases/

Lista oddziałów, wersji, poprawek i aktualizacji CR/LTS Plus oraz przypomnienia o kompatybilności aktualizacji.

S20 — NGINX JavaScript / njs Oficjalny biuletyn bezpieczeństwa

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

Zawiera październik 2026 r. njs 1.0.2 i powiązaną weryfikację XML, problemy z wyczerpaniem pamięci.

S21 — Kubernetes: Oficjalne instrukcje społeczności ingress-nginx dotyczące wycofania

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

Należy pamiętać, że projekt wstrzymał wydawanie nowych wersji i poprawek bezpieczeństwa w marcu 2026 r. i zaleca się migrację utrzymywanego kontrolera lub Gateway API.

S22 — Oficjalna kontrola serwisowa NGINX i instrukcje aktualizacji plików binarnych online

• https://nginx.org/en/docs/control.html

Rozróżnij metody ponownego ładowania konfiguracji, restartu i aktualizacji plików wykonywalnych online w celu akceptacji przełączania procesów.

S23 — Rządowe powiadomienie dotyczące bezpieczeństwa: luka w zabezpieczeniach NGINX z maja 2026 r. związana z przepisaniem

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

Podaj historyczne informacje o ryzyku i sugestie dotyczące aktualizacji zabezpieczeń dla CVE-2026-42945; orzeczenia dotyczące eksploatacji w środowisku naturalnym powinny opierać się na ogłoszeniu agencji wydanym w danym momencie i na dalszych dowodach zdarzenia.

S24 — F5: CVE-2026-95101 i CVE-2026-97629 Powiadomienia dostawców

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

Obejmuje ryzyko odpowiednio wprowadzenia treści żądania HTTP/3 i automatycznej rotacji klucza biletu TLS.

S25 — F5: CVE-2026-97205 Ogłoszenie dostawcy

• https://my.f5.com/manage/s/article/K000162608

Opis Warunki wyzwalania SSI/AIO i potencjalne ryzyko uszkodzenia pamięci.

Aktualizacja zabezpieczeń NGINX: sprawdzanie konfiguracji, aktualizacje i weryfikacja