Krytyczna luka w NGINX: CVE-2026-42533 grozi awariami workerów i potencjalnym RCE

Wprowadzenie do problemu / definicja

W połowie lipca 2026 roku ujawniono krytyczną podatność w NGINX oznaczoną jako CVE-2026-42533. Błąd dotyczy przepełnienia bufora sterty w procesie worker i może zostać wywołany zdalnie przez nieuwierzytelnionego atakującego za pomocą odpowiednio przygotowanych żądań HTTP.

W praktyce oznacza to ryzyko awarii usługi, restartów procesów worker oraz, w określonych scenariuszach, możliwość doprowadzenia do zdalnego wykonania kodu. Ze względu na powszechne wykorzystanie NGINX w środowiskach produkcyjnych problem należy traktować jako incydent wysokiego priorytetu.

W skrócie

• Podatność obejmuje szeroki zakres wersji NGINX od 0.9.6 do 1.31.2.
• Poprawki udostępniono w wersjach 1.30.4 i 1.31.3 oraz w NGINX Plus 37.0.3.1.
• Luka ujawnia się w określonych konfiguracjach wykorzystujących dyrektywę map, wyrażenia regularne i odwołania do przechwyconych grup regex.
• Najbardziej prawdopodobnym skutkiem jest odmowa usługi i niestabilność workerów, ale analiza techniczna wskazuje również na możliwość budowy łańcucha prowadzącego do RCE.

Kontekst / historia

NGINX od lat pozostaje jednym z kluczowych serwerów HTTP i reverse proxy wykorzystywanych w infrastrukturze internetowej. Każda krytyczna luka w jego mechanizmach przetwarzania żądań ma więc bezpośredni wpływ na bezpieczeństwo aplikacji webowych, platform API, środowisk chmurowych oraz warstw pośredniczących.

CVE-2026-42533 wpisuje się w szerszy trend błędów pamięci ujawnianych w oprogramowaniu obsługującym złożone operacje na danych wejściowych. W tym przypadku problem nie wynika wyłącznie z podatnej wersji binarnej, ale także z konkretnej logiki konfiguracji, co utrudnia szybką ocenę ekspozycji w dużych środowiskach.

Znaczenie podatności zwiększa również fakt, że ryzyko może obejmować nie tylko samodzielnie utrzymywane instancje NGINX, lecz także rozwiązania zależne, takie jak kontrolery ingress, komponenty bezpieczeństwa aplikacyjnego czy platformy zarządzające oparte o ten silnik.

Analiza techniczna

Źródłem problemu jest nieprawidłowa obsługa danych w dwufazowym mechanizmie ewaluacji wyrażeń. NGINX najpierw wylicza rozmiar bufora potrzebnego do zapisania wyniku, a następnie w drugim przebiegu umieszcza w nim finalne dane. W podatnej ścieżce obie fazy korzystają ze współdzielonego stanu przechwyconych grup z wyrażeń regularnych.

Do błędu dochodzi wtedy, gdy konfiguracja używa dyrektywy map opartej na regexach, a wynikowa zmienna zostaje później osadzona w wyrażeniu tekstowym po wcześniejszym użyciu przechwycenia z innego dopasowania. W takiej sytuacji stan przechwyceń może zostać nadpisany pomiędzy obliczeniem rozmiaru bufora a właściwym zapisem danych.

Efekt jest typowy dla przepełnienia bufora sterty: alokacja odbywa się na podstawie wcześniejszego, mniejszego wyniku, natomiast zapis korzysta już z innej, potencjalnie większej wartości kontrolowanej przez atakującego. To sprawia, że możliwe są awarie procesu worker, nieprzewidywalne zachowanie usługi, a w bardziej złożonych scenariuszach także warunki sprzyjające dalszej eksploatacji.

Szczególnie istotne jest to, że podatność nie aktywuje się automatycznie w każdej instalacji. O realnej ekspozycji decyduje konkretna składnia, kolejność użycia zmiennych i sposób łączenia przechwyceń regex w konfiguracji. W praktyce oznacza to konieczność przeglądu logiki konfiguracyjnej, a nie tylko porównania numeru wersji.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem CVE-2026-42533 jest odmowa usługi. Atakujący może doprowadzić do segmentacji procesu worker, jego restartu albo niestabilnej pracy instancji NGINX, co przekłada się na spadek dostępności aplikacji i usług publikowanych za tym serwerem.

Wyższy poziom ryzyka pojawia się tam, gdzie przepełnienie bufora może zostać połączone z dodatkowymi technikami eksploatacji, takimi jak ujawnienie danych z pamięci czy obejście mechanizmów ochrony pamięci. Nawet jeśli pełne RCE wymaga bardziej złożonych warunków, sam fakt istnienia zdalnie wyzwalanego błędu pamięci w komponencie obsługującym ruch sieciowy stanowi poważne zagrożenie operacyjne.

Problem jest dodatkowo istotny dla organizacji korzystających z rozbudowanych, warstwowych konfiguracji. Podatny wzorzec może pozostać ukryty w include’ach, generatorach szablonów lub konfiguracjach tworzonych automatycznie, przez co identyfikacja ryzyka może wymagać pełnego przeglądu ścieżki przetwarzania konfiguracji.

Rekomendacje

Priorytetowym działaniem powinno być niezwłoczne wdrożenie poprawek producenta. Organizacje korzystające z podatnych wersji powinny przejść do NGINX 1.30.4 lub 1.31.3, a w przypadku środowisk komercyjnych do odpowiedniego wydania NGINX Plus zawierającego łatę.

Do czasu aktualizacji warto podjąć następujące działania ograniczające ryzyko:

• przeprowadzić audyt konfiguracji pod kątem użycia map z wyrażeniami regularnymi;
• zidentyfikować miejsca, w których zmienne wynikowe z map są używane razem z przechwyceniami takimi jak $1, $2 i kolejnymi;
• sprawdzić kolejność użycia przechwyceń regex oraz zmiennych wynikowych;
• monitorować logi błędów pod kątem restartów workerów, segmentacji i nietypowych awarii po żądaniach HTTP;
• zweryfikować zależne produkty oraz komponenty bazujące na NGINX;
• ograniczyć ekspozycję publiczną instancji, jeśli natychmiastowa analiza i aktualizacja nie są możliwe.

Jeżeli pełne wdrożenie poprawek musi zostać odłożone, tymczasowym rozwiązaniem może być przebudowa konfiguracji w taki sposób, aby unikać podatnych wzorców opartych na przechwyceniach regex. Należy jednak traktować to wyłącznie jako środek przejściowy, a nie pełną remediację.

Podsumowanie

CVE-2026-42533 to krytyczna luka w NGINX wynikająca z błędu w obsłudze przechwyceń regex i dwufazowej ewaluacji wyrażeń. Choć jej aktywacja zależy od konkretnej konfiguracji, potencjalne skutki są poważne i obejmują zarówno awarie procesów worker oraz odmowę usługi, jak i możliwość budowy ścieżki prowadzącej do zdalnego wykonania kodu.

Z perspektywy zespołów bezpieczeństwa i administratorów oznacza to konieczność szybkiego działania: aktualizacji oprogramowania, przeglądu konfiguracji oraz weryfikacji wszystkich produktów opartych na NGINX. W środowiskach o krytycznym znaczeniu odkładanie tych działań może przełożyć się na realne ryzyko zakłócenia usług i kompromitacji infrastruktury.

Źródła

• https://thehackernews.com/2026/07/critical-nginx-vulnerability-can-crash.html
• https://nginx.org/en/security_advisories.html
• https://nginx.org/en/CHANGES
• https://www.cve.org/CVERecord?id=CVE-2026-42533