NGINX 1.30.6 i 1.31.7: pięć poprawek, których nie ocenia się samym CVSS

Jedna aktualizacja NGINX zamyka pięć różnych klas ryzyka. Nie każda instalacja realizuje jednak podatną ścieżkę. Znaczenie mają dyrektywy alias i rewrite, użycie HTTP/3, rotacja kluczy biletów sesji TLS, asynchroniczne operacje wejścia-wyjścia oraz sposób ewaluacji skryptów i zmiennych.

14 października projekt opublikował stabilne wydanie NGINX 1.30.6 i główne 1.31.7. Oficjalna lista advisory wskazuje, że wersje te zawierają poprawki dla CVE-2026-15176, CVE-2026-93479, CVE-2026-95101, CVE-2026-97629 i CVE-2026-97205. Dziennik wydań NGINX potwierdza publikację obu wersji.

Wniosek Breachroad: najpierw ustal, które funkcje są rzeczywiście aktywne, ale nie używaj analizy konfiguracji jako wymówki do bezterminowego odłożenia aktualizacji. Ekspozycja może pojawić się po zmianie szablonu, wdrożeniu nowej aplikacji albo włączeniu HTTP/3.

Pięć podatności, pięć pytań o konfigurację

CVE-2026-15176: alias, rewrite i $request_filename

Przepełnienie bufora może wystąpić w określonej konfiguracji łączącej alias z rewrite, gdy wynik korzysta z $request_filename. Biuletyn F5 K000162416 opisuje nieuwierzytelniony atak przygotowanym żądaniem oraz możliwość odmowy usługi. Wykonanie kodu wymaga dodatkowych warunków, między innymi wyłączonego lub skutecznie ominiętego ASLR, dlatego nie należy przedstawiać RCE jako automatycznego skutku każdego podatnego serwera.

Do przeglądu trafiają konfiguracje z alias i rewrite, odwołania do $request_filename w set lub return oraz formaty logów dostępu wykorzystujące tę zmienną. Oficjalny zakres obejmuje wersje od 0.1.29 do 1.31.6.

CVE-2026-93479: przepełnienie podczas ewaluacji skryptu

Drugi błąd pamięci dotyczy ewaluacji skryptów i złożonych wartości. Zakres podatnych wydań jest węższy: główna gałąź 1.31.2–1.31.6 i stabilna 1.30.0–1.30.5. Administrator powinien sprawdzić nie tylko plik z repozytorium, ale także końcową konfigurację wygenerowaną przez kontroler ingress, szablony lub system zarządzania.

CVE-2026-95101: wstrzyknięcie treści żądania przez HTTP/3

Ten problem dotyczy obsługi HTTP/3 w wersjach 1.25.0–1.31.6. Jeżeli HTTP/3/QUIC nie jest włączony i nie jest wystawiony przez daną warstwę, podatna ścieżka może być nieosiągalna. Trzeba to jednak sprawdzić na działającym systemie, łącznie z usługami brzegowymi, a nie wywnioskować z jednego pliku konfiguracyjnego.

CVE-2026-97629: bilety sesji TLS

Podatność w rotacji kluczy biletów sesji TLS może prowadzić do podrobienia sesji. Oficjalny zakres obejmuje wersje 1.23.2–1.31.6. Oceniając wpływ, sprawdź konfigurację TLS na każdym węźle, współdzielenie kluczy i warstwy terminujące szyfrowanie. NGINX uruchomiony za load balancerem nie zawsze jest miejscem, w którym kończy się TLS.

CVE-2026-97205: use-after-free z AIO

Błąd use-after-free występuje przy asynchronicznym I/O i obejmuje szeroki zakres 0.8.11–1.31.6. Pytanie brzmi nie tylko „czy AIO jest zapisane w szablonie”, ale czy aktywna konfiguracja i system operacyjny korzystają z tej ścieżki przy obsłudze plików.

Od czego zacząć inwentaryzację

Nie ograniczaj wyszukiwania do maszyn wirtualnych nazwanych „nginx”. Serwer może znajdować się:

• w obrazie kontenera aplikacji lub sidecarze;
• w kontrolerze Kubernetes Ingress;
• w urządzeniu dostawcy, bramie API albo panelu hostingowym;
• w starszym środowisku testowym nadal osiągalnym z internetu;
• jako pakiet dystrybucji Linuksa z numerem wersji innym niż wydanie upstream.

W przypadku pakietów systemowych sam niższy numer nie zawsze oznacza brak poprawki. Dystrybucja mogła przenieść ją wstecz bez zmiany bazowego numeru w sposób oczekiwany dla upstream. Decyzję trzeba oprzeć na biuletynie i changelogu dostawcy pakietu. Z kolei kontener oznaczony tagiem latest nie jest dowodem, że działający pod otrzymał nowy obraz.

Przygotuj listę instancji z właścicielem, źródłem pakietu, rzeczywistym wynikiem nginx -V, aktywną konfiguracją i informacją, która warstwa przyjmuje ruch od użytkownika.

Plan aktualizacji bez zgadywania

1. Ustal źródło oprogramowania. Dla upstream przejdź co najmniej do 1.30.6 albo 1.31.7. Dla dystrybucji, NGINX Plus i urządzeń zarządzanych stosuj wersję wskazaną przez ich producenta.
2. Wyeksportuj aktywną konfigurację. Uwzględnij wszystkie pliki, wartości wstrzykiwane przez pipeline i wynik generowania kontrolera.
3. Oceń osiągalność pięciu ścieżek. Sprawdź alias/rewrite, $request_filename, HTTP/3, bilety TLS oraz AIO. Udokumentuj wynik zamiast oznaczać całą flotę jednym statusem.
4. Przetestuj konfigurację i ruch. Po zbudowaniu nowego obrazu lub pakietu sprawdź składnię, routing, pliki statyczne, logowanie, TLS i HTTP/3 na stagingu.
5. Wdróż etapami. Obserwuj błędy 4xx/5xx, restarty workerów, zużycie pamięci, handshake TLS i różnice w ruchu QUIC.
6. Potwierdź wersję procesu. Zaktualizowany plik na dysku nie wystarcza, jeśli stary proces lub pod nadal obsługuje ruch.

Jeżeli NGINX jest częścią zamkniętego urządzenia lub kontrolera, nie zastępuj samodzielnie binariów upstream. Taka zmiana może zerwać wsparcie i integralność produktu. Wymagaj od dostawcy identyfikatora poprawki, terminu oraz środków ograniczających ryzyko.

Czy trzeba traktować to jak incydent

Oficjalne komunikaty opisują podatności i poprawione wydania, ale nie potwierdzają w tych advisory aktywnego wykorzystania wszystkich pięciu luk. Obecność podatnej wersji jest zadaniem podatnościowym, a nie automatycznym dowodem włamania.

Triage incydentowy staje się uzasadniony, gdy pojawiają się niewyjaśnione crashe workerów, skoki błędów 5xx, nieoczekiwane zachowanie żądań HTTP/3, anomalie sesji TLS albo korelacja z przygotowanymi żądaniami. Zachowaj logi i zrzuty potrzebne do analizy przed masowym restartem.

Fakty i nasze zalecenia

Numery CVE, zakresy wersji, poprawione wydania i zależności konfiguracyjne pochodzą z oficjalnych advisory NGINX i F5. Źródła nie stwierdzają, że każdy serwer w podanym zakresie jest osiągalny tą samą ścieżką ani że doszło do kompromitacji.

Macierz osiągalności, etapowe wdrożenie i potwierdzanie wersji działającego procesu są rekomendacjami Breachroad. Uzupełniają wcześniejszą analizę CVE-2026-42533 zależnej od map i regex. Zespoły mogą uporządkować odpowiedzialność za takie zmiany podczas szkoleń cyberbezpieczeństwa dla organizacji, a konfigurację bramy i aplikacji sprawdzić przez testy bezpieczeństwa aplikacji webowych i API.