--- title: "Luki w zabezpieczeniach NGINX: przyczyny, poprawki i weryfikacja produkcji" description: "Przejrzyj pięć luk w zabezpieczeniach NGINX z października 2026 r., wymagania wstępne dotyczące ich konfiguracji, poprawki specyficzne dla branży, backporty dystrybucji i weryfikację produkcji." language: "pl" url: "https://keendigit.com/pl/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # Luki w zabezpieczeniach NGINX: przyczyny, poprawki i weryfikacja produkcji Przejrzyj pięć luk w zabezpieczeniach NGINX z października 2026 r., wymagania wstępne dotyczące ich konfiguracji, poprawki specyficzne dla branży, backporty dystrybucji i weryfikację 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1), 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. [S1](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/pl/insights/nginx-remediation-guide#source-2) 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. [S13](https://keendigit.com/pl/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/pl/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/pl/insights/nginx-remediation-guide#source-15) 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. [S1](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/pl/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pl/insights/nginx-remediation-guide#source-4) 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. [S3](https://keendigit.com/pl/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pl/insights/nginx-remediation-guide#source-4)[S8](https://keendigit.com/pl/insights/nginx-remediation-guide#source-8)[S12](https://keendigit.com/pl/insights/nginx-remediation-guide#source-12) ## 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. [S1](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/pl/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/pl/insights/nginx-remediation-guide#source-3) 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. [S1](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/pl/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pl/insights/nginx-remediation-guide#source-4) | 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. [S1](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/pl/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pl/insights/nginx-remediation-guide#source-4) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-4) 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. [S5](https://keendigit.com/pl/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/pl/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/pl/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/pl/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/pl/insights/nginx-remediation-guide#source-9) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-5) Typowa kombinacja (używana wyłącznie jako kontrprzykład do audytu konfiguracji, wdrażanie nie jest zalecane): ```nginx # 仅用于识别风险模式：不是修复配置 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. [S5](https://keendigit.com/pl/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/pl/insights/nginx-remediation-guide#source-10) 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. [S5](https://keendigit.com/pl/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/pl/insights/nginx-remediation-guide#source-10) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-6) | 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. [S6](https://keendigit.com/pl/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/pl/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/pl/insights/nginx-remediation-guide#source-17) 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-11) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-7) 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-7) 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. [S4](https://keendigit.com/pl/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/pl/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/pl/insights/nginx-remediation-guide#source-25) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-8) 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. [S8](https://keendigit.com/pl/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/pl/insights/nginx-remediation-guide#source-18) 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-24) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-9) Kombinacje wdrożeń obarczone wysokim ryzykiem to zazwyczaj: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 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”. [S9](https://keendigit.com/pl/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/pl/insights/nginx-remediation-guide#source-12) 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-24) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-4) - Żą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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-23) ## 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. [S1](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/pl/insights/nginx-remediation-guide#source-2) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-13) | 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-13) ### 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: ```text 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. [S14](https://keendigit.com/pl/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/pl/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/pl/insights/nginx-remediation-guide#source-16) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-19) | | 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-20) | | 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-21) | ### 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 ```bash # 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: ```bash 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): ```bash 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. [S13](https://keendigit.com/pl/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/pl/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/pl/insights/nginx-remediation-guide#source-15) Oficjalny pakiet nginx.org: ```bash # 先确认仓库来自 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 ```bash 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-22) 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. [S3](https://keendigit.com/pl/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/pl/insights/nginx-remediation-guide#source-4) ### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-5) ### 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: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[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ę. [S3](https://keendigit.com/pl/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/pl/insights/nginx-remediation-guide#source-6) ### 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: ```nginx # 在适当的 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-7) ### 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: ```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. [S8](https://keendigit.com/pl/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/pl/insights/nginx-remediation-guide#source-18) ### 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 # 在 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. [S9](https://keendigit.com/pl/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/pl/insights/nginx-remediation-guide#source-12) 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-12) ### 5.7 Rola systemu operacyjnego i ochrony granic ```bash # 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-4) ### 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ę. [S5](https://keendigit.com/pl/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/pl/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/pl/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/pl/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/pl/insights/nginx-remediation-guide#source-9) ### 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`: ```diff - 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-5) ### 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: ```diff - 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-6) 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`: ```c #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: ```c 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-7) ### 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: ```c 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-8) ### 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`: ```diff 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-9) ### 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: [S1](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/pl/insights/nginx-remediation-guide#source-2) | 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-1) #### 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-23) „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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-20) - 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-19) - 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](https://keendigit.com/pl/insights/nginx-remediation-guide#source-21) ## 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 - 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 - - 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 - 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 - 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 - Odpowiada kontroli stanu `alias` i `r->uri_changed` w `ngx_http_map_uri_to_path()`. ### S6 — Oficjalne zatwierdzenie źródła: CVE-2026-93479 - Odpowiada długości skryptu HTTP/Stream i logice alokacji zarezerwowanego bufora. ### S7 — Oficjalne zatwierdzenie źródła: CVE-2026-97205 - 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 - 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 - Odpowiada wszystkim gniazdom kluczy podczas synchronizacji TLS Rotacja biletów sesji. ### S10 — F5: CVE-2026-15176 Ogłoszenie dostawcy - Lista czynników wyzwalających, takich jak `alias`, `rewrite`, `$request_filename` i dzienniki dostępu. ### S11 — F5: CVE-2026-93479 Ogłoszenie dostawcy - Wyświetl listę przechwyconych wyrażeń regularnych mapy, ścieżkę root i zarejestruj warunki oceny zmiennych. ### S12 — NGINX oficjalna dokumentacja modułu TLS/SSL - 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) - 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) - 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 - 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 - 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 - 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 - - 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 - Lista oddziałów, wersji, poprawek i aktualizacji CR/LTS Plus oraz przypomnienia o kompatybilności aktualizacji. ### S20 — NGINX JavaScript / njs Oficjalny biuletyn bezpieczeństwa - - 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 - - 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 - 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 - - 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 - - Obejmuje ryzyko odpowiednio wprowadzenia treści żądania HTTP/3 i automatycznej rotacji klucza biletu TLS. ### S25 — F5: CVE-2026-97205 Ogłoszenie dostawcy - Opis Warunki wyzwalania SSI/AIO i potencjalne ryzyko uszkodzenia pamięci. [Aktualizacja zabezpieczeń NGINX: sprawdzanie konfiguracji, aktualizacje i weryfikacja](https://keendigit.com/pl/news/nginx-security-update) ## Konsultacje dotyczące konserwacji zabezpieczeń Nie masz pewności, jak zmiany zaufania certyfikatów wpływają na Twoje systemy? Możemy pomóc ocenić dotkniętych klientów i zaplanować aktualizacje zabezpieczeń. [Omów aktualizacje zabezpieczeń]() [Oryginalna strona]() · [Indeks treści]() KeenDigit LLC · Identyfikator zgłoszenia w Wyoming: 2026-002106155 [Sprawdź to u Sekretarza Stanu Wyoming]() © 2026 KeenDigit LLC · Sheridana, Wyoming, USA · Wszelkie prawa zastrzeżone.