Krytyczna luka w module rewrite NGINX może prowadzić do niezautoryzowanego RCE

Wprowadzenie do problemu / definicja

W ekosystemie NGINX ujawniono krytyczną podatność typu heap buffer overflow w module ngx_http_rewrite_module, oznaczoną jako CVE-2026-42945. Błąd dotyczy logiki przetwarzania reguł rewrite i w określonych konfiguracjach może prowadzić do zdalnego wykonania kodu bez uwierzytelnienia albo do odmowy usługi.

To szczególnie istotne zagrożenie, ponieważ NGINX jest jednym z najczęściej wykorzystywanych serwerów HTTP i reverse proxy w środowiskach produkcyjnych. W praktyce oznacza to, że podatność może dotknąć nie tylko klasyczne serwery WWW, ale również bramy aplikacyjne, load balancery, kontrolery ingress oraz rozwiązania bezpieczeństwa oparte na tej platformie.

W skrócie

• Podatność CVE-2026-42945 dotyczy modułu ngx_http_rewrite_module w NGINX.
• Wadliwa logika może zostać wywołana przez odpowiednio spreparowane żądanie HTTP.
• Warunkiem jest użycie określonych kombinacji dyrektyw rewrite, if lub set wraz z nienazwanymi przechwyceniami, takimi jak $1 i $2.
• Skutkiem może być awaria procesu worker, pętla restartów, a w mniej bezpiecznych środowiskach również zdalne wykonanie kodu.
• Problem miał pozostawać obecny przez około 18 lat, co czyni go jednym z bardziej niepokojących przypadków długowiecznych błędów infrastrukturalnych.

Kontekst / historia

NGINX od lat stanowi jeden z filarów nowoczesnej infrastruktury internetowej. Jest wykorzystywany zarówno jako serwer frontowy, jak i warstwa pośrednicząca dla aplikacji, API oraz usług wewnętrznych. Z tego powodu każda luka w jego podstawowych modułach ma potencjalnie szeroki wpływ operacyjny.

Ujawniony problem został opisany jako wada obecna od około 18 lat. Taki horyzont czasowy pokazuje, że nawet dojrzałe i szeroko audytowane komponenty mogą zawierać trudne do wykrycia błędy, aktywowane tylko w specyficznych scenariuszach konfiguracyjnych.

Poprawki opublikowano dla wspieranych linii rozwojowych NGINX Open Source oraz odpowiednich wydań NGINX Plus. Jednocześnie część starszych, niewspieranych wersji nie otrzyma aktualizacji bezpieczeństwa, co zwiększa ryzyko w środowiskach opartych na przestarzałych buildach lub nieaktualnych obrazach kontenerowych.

Równolegle opublikowano także informacje o innych błędach bezpieczeństwa dotyczących modułów SCGI, uWSGI, SSL i charset. To sygnał, że organizacje powinny potraktować ten cykl aktualizacji szerzej, jako przegląd bezpieczeństwa całej warstwy HTTP, a nie tylko pojedynczej podatności.

Analiza techniczna

Sedno problemu znajduje się w module ngx_http_rewrite_module, odpowiedzialnym za modyfikowanie URI i sterowanie przepływem przetwarzania żądań na podstawie reguł konfiguracyjnych. Moduł ten jest powszechnie używany do przekierowań, normalizacji ścieżek, warunkowego ustawiania zmiennych oraz rozgałęziania logiki ruchu.

Podatność ujawnia się w specyficznej kombinacji warunków konfiguracyjnych. Chodzi o przypadki, w których dyrektywa rewrite jest zestawiona z kolejną dyrektywą rewrite, if lub set, a konfiguracja wykorzystuje nienazwane grupy przechwytywania wyrażeń regularnych, do których odwołuje się jako $1, $2 i kolejne. Dodatkowym warunkiem jest obecność znaku zapytania w łańcuchu zastąpienia.

W takim scenariuszu odpowiednio spreparowane żądanie HTTP może doprowadzić do błędnej operacji na pamięci i skutkować heap buffer overflow w procesie roboczym NGINX. Ponieważ atak nie wymaga uwierzytelnienia, próg wejścia dla potencjalnego napastnika pozostaje niski, szczególnie w systemach publicznie dostępnych z internetu.

Efekt eksploatacji zależy od architektury procesu, wersji kompilacji oraz aktywnych mechanizmów ochronnych systemu operacyjnego. W bardziej typowym scenariuszu dochodzi do awarii procesu worker i jego restartu. W mniej zabezpieczonych środowiskach, zwłaszcza przy osłabionych mechanizmach ochrony pamięci, błąd może jednak stworzyć warunki do zdalnego wykonania kodu w kontekście procesu NGINX.

Istotne jest również to, że nie wszystkie instalacje tej samej wersji NGINX są narażone w identycznym stopniu. Poziom ekspozycji zależy od konkretnej konfiguracji reguł przepisywania, co oznacza, że analiza ryzyka wymaga przeglądu realnych plików konfiguracyjnych, a nie tylko samej wersji oprogramowania.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem podatności jest możliwość wywołania odmowy usługi. Jeżeli pojedyncze lub powtarzane żądania prowadzą do awarii workerów, instancja może wejść w stan niestabilności, a aplikacje obsługiwane przez serwer staną się okresowo niedostępne.

Znacznie poważniejszy scenariusz obejmuje zdalne wykonanie kodu. Choć osiągnięcie stabilnego RCE zwykle zależy od dodatkowych warunków środowiskowych, sam charakter błędu klasyfikuje podatność jako krytyczną. Kompromitacja procesu NGINX może umożliwić dalszą penetrację infrastruktury, manipulację ruchem aplikacyjnym, podsłuch komunikacji lub przygotowanie gruntu pod ruch lateralny.

Ryzyko rośnie szczególnie w środowiskach:

• publicznie dostępnych z internetu,
• obsługujących wiele aplikacji na jednej instancji,
• wykorzystujących rozbudowane reguły rewrite,
• opartych na starszych obrazach kontenerowych lub niewspieranych wersjach,
• z osłabionymi zabezpieczeniami pamięci i ograniczoną segmentacją uprawnień.

Ze względu na skalę wdrożeń NGINX nawet warunkowy charakter podatności nie zmniejsza istotnie jej znaczenia. Wystarczy bowiem, że podatna konfiguracja występuje w części organizacji, aby zagrożenie miało szeroki wymiar praktyczny.

Rekomendacje

Podstawowym działaniem powinno być niezwłoczne wdrożenie wersji NGINX zawierających poprawki bezpieczeństwa. Organizacje powinny przeprowadzić pełną inwentaryzację instancji, obejmującą serwery fizyczne, maszyny wirtualne, kontenery, obrazy bazowe, appliance’e oraz komponenty pośrednio wykorzystujące NGINX.

W praktyce warto przyjąć następujący plan działań:

• zidentyfikować konfiguracje używające rewrite, if i set z odwołaniami typu $1 i $2,
• sprawdzić, czy w ciągach zastąpienia występuje znak ?,
• nadać priorytet systemom wystawionym do internetu oraz krytycznym aplikacjom biznesowym,
• zaktualizować oprogramowanie do wspieranych wersji z poprawką,
• przeprowadzić testy regresyjne po wdrożeniu zmian.

Jeżeli natychmiastowe łatanie nie jest możliwe, tymczasowym obejściem może być zastąpienie nienazwanych przechwyceń nazwanymi grupami wyrażeń regularnych. Taka zmiana nie powinna być jednak traktowana jako pełny substytut aktualizacji, lecz wyłącznie jako środek ograniczający ekspozycję.

Dodatkowo warto wdrożyć działania wzmacniające bezpieczeństwo operacyjne:

• monitorowanie restartów workerów i wzrostu błędów 5xx,
• analizę logów pod kątem nietypowych URI i wzorców ataków,
• utrzymanie ASLR oraz innych zabezpieczeń pamięci w aktywnym stanie,
• ograniczenie uprawnień procesu NGINX i ruchu lateralnego z hostów frontowych,
• przegląd złożonych reguł transformacji żądań w konfiguracjach reverse proxy,
• dodanie kontroli statycznych dla plików konfiguracyjnych w pipeline’ach DevSecOps.

Podsumowanie

CVE-2026-42945 to przykład podatności o bardzo wysokiej wadze operacyjnej. Dotyczy popularnego komponentu brzegowego, jest osiągalna bez uwierzytelnienia i w określonych warunkach może prowadzić do zdalnego wykonania kodu. Nawet jeśli eksploatacja kończy się jedynie awarią workerów, konsekwencją może być realna niedostępność usług i zakłócenie pracy aplikacji.

Najważniejsze działania po stronie administratorów to szybka aktualizacja NGINX, przegląd konfiguracji modułu rewrite oraz wdrożenie monitoringu pod kątem awarii i nietypowych żądań. Organizacje traktujące NGINX jako krytyczny element swojej warstwy dostępowej powinny uznać ten biuletyn za pilny i wymagający natychmiastowej reakcji.

Źródła

1. The Hacker News — https://thehackernews.com/2026/05/18-year-old-nginx-rewrite-module-flaw.html
2. NGINX — Latest News / Releases — https://nginx.org/
3. NGINX Download and release branches — https://nginx.org/en/download.html
4. myF5 Security Advisories — https://my.f5.com/
5. depthfirst Research — https://depthfirst.com/research