Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
CVE-2026-42945 to krytyczna podatność w serwerze NGINX, związana z modułem ngx_http_rewrite_module. Błąd ma charakter heap-based buffer overflow i może zostać wywołany przez odpowiednio przygotowane żądanie HTTP, co w praktyce prowadzi do awarii procesów worker, a w bardziej sprzyjających warunkach potencjalnie także do zdalnego wykonania kodu.
Problem dotyczy zarówno wydań open source, jak i wybranych komercyjnych wariantów NGINX Plus. Szczególne znaczenie ma fakt, że podatność nie jest wyłącznie teoretyczna — pojawiły się już sygnały o jej aktywnym wykorzystywaniu.
W skrócie
- CVE-2026-42945 to krytyczna luka pamięciowa w module rewrite NGINX.
- Najbardziej prawdopodobnym skutkiem ataku jest denial of service poprzez crash procesów worker.
- W określonych konfiguracjach nie można wykluczyć scenariusza RCE.
- Najbardziej narażone są publicznie dostępne instancje korzystające z określonych reguł
rewrite,ifiset. - Priorytetem powinno być szybkie wdrożenie poprawek i przegląd konfiguracji.
Kontekst / historia
Analizy wskazują, że źródło problemu mogło znajdować się w kodzie przez około 18 lat. To czyni CVE-2026-42945 kolejnym przykładem długo ukrytej podatności w szeroko stosowanym komponencie infrastrukturalnym, od którego zależy działanie ogromnej liczby serwisów internetowych i systemów API.
Wada została publicznie nagłośniona w maju 2026 roku. Jej znaczenie szybko wzrosło po pojawieniu się doniesień o aktywności exploitacyjnej oraz po niezależnym potwierdzeniu możliwości wywoływania awarii workerów w kontrolowanych testach. Z punktu widzenia zespołów bezpieczeństwa oznacza to przejście od ryzyka czysto technicznego do realnego zagrożenia operacyjnego.
Zakres dotkniętych wersji obejmuje szeroki przedział wydań NGINX Open Source oraz wybrane wydania NGINX Plus, co zwiększa prawdopodobieństwo ekspozycji w środowiskach produkcyjnych, szczególnie tam, gdzie aktualizacje infrastruktury są wdrażane z opóźnieniem.
Analiza techniczna
Źródłem podatności jest niespójność pomiędzy obliczaniem wielkości bufora a rzeczywistym zapisem danych podczas przetwarzania reguł przepisywania URI. W określonych scenariuszach NGINX korzysta z różnych mechanizmów escapowania podczas alokacji pamięci i późniejszego zapisu wyniku, co może doprowadzić do zapisania większej ilości danych niż pierwotnie przewidziano.
Na podatność szczególnie narażone są konfiguracje, w których dyrektywa rewrite wykorzystuje nienazwane grupy przechwytywania, takie jak $1 lub $2, a ciąg zastępczy zawiera znak zapytania. Istotne jest również to, aby po takiej regule następowała kolejna instrukcja rewrite, if albo set. W takim układzie niektóre znaki z żądania, między innymi +, % czy &, mogą zostać przetworzone w sposób zwiększający długość końcowego ciągu, co skutkuje wyjściem poza granice zaalokowanego bufora.
Z perspektywy bezpieczeństwa ważne jest, że nadmiarowo zapisywane dane pochodzą z kontrolowanego przez atakującego żądania HTTP. Oznacza to, że uszkodzenie pamięci nie musi być przypadkowe. W efekcie luka może zostać wykorzystana nie tylko do destabilizacji procesu, ale w określonych warunkach także do bardziej zaawansowanych form eksploatacji. Jednocześnie osiągnięcie stabilnego RCE nie jest uznawane za trywialne i zwykle wymaga dodatkowych osłabień po stronie systemu, takich jak brak skutecznych mechanizmów ochrony pamięci.
Warto podkreślić, że sama obecność podatnej wersji NGINX nie oznacza automatycznie pełnej podatności na atak. Konieczna jest jeszcze odpowiednia konfiguracja reguł oraz możliwość trafienia przez atakującego w konkretny wzorzec przetwarzania URI. To ogranicza skalę ataków masowych, ale nie zmniejsza zagrożenia dla systemów publicznie dostępnych i wykorzystujących rozbudowaną logikę rewrite.
Konsekwencje / ryzyko
Najbardziej bezpośrednim skutkiem wykorzystania CVE-2026-42945 jest denial of service. Atakujący może doprowadzać do awarii workerów, co przekłada się na przerwy w obsłudze ruchu, zwiększoną liczbę błędów HTTP, problemy z wydajnością oraz ryzyko przeciążenia mechanizmów odpowiedzialnych za restart usług. W środowiskach wysokiej dostępności taki scenariusz nadal może powodować zauważalne zakłócenia biznesowe.
Poważniejszym wariantem jest potencjalne zdalne wykonanie kodu. Choć taki scenariusz wymaga bardziej sprzyjających warunków technicznych i odpowiedniego przygotowania exploita, jego skutki mogłyby być znacznie szersze niż sam DoS. Przejęcie warstwy reverse proxy otwiera drogę do przechwytywania lub modyfikowania ruchu, dalszej kompromitacji backendów, wdrożenia złośliwych komponentów oraz poruszania się wewnątrz infrastruktury.
Podwyższone ryzyko dotyczy szczególnie organizacji, które:
- wystawiają NGINX bezpośrednio do internetu,
- używają złożonych reguł
rewritei warunkówif, - utrzymują starsze lub niestandardowo budowane pakiety,
- nie mają pełnej inwentaryzacji konfiguracji reverse proxy,
- stosują osłabione mechanizmy hardeningu hosta.
Rekomendacje
Najważniejszym krokiem obronnym jest niezwłoczne wdrożenie poprawek dostarczonych przez producenta lub dystrybutora systemu. Organizacje powinny w pierwszej kolejności ustalić, które instancje NGINX działają w podatnym zakresie wersji, a następnie nadać najwyższy priorytet aktualizacjom w środowiskach internet-facing.
Równolegle należy przeprowadzić przegląd konfiguracji pod kątem użycia dyrektyw rewrite, if i set, szczególnie tam, gdzie występują nienazwane przechwycenia oraz bardziej złożone przekształcenia URI. Jeżeli natychmiastowa aktualizacja nie jest możliwa, warto rozważyć tymczasowe uproszczenie najbardziej ryzykownych reguł oraz zwiększenie monitoringu anomalii w ruchu HTTP.
- Monitorować logi NGINX pod kątem nietypowych i powtarzalnych manipulacji URI.
- Obserwować restarty, crashe i niestandardowe zachowanie procesów worker.
- Wdrożyć lub zaktualizować reguły detekcyjne w IDS, SIEM i WAF.
- Zweryfikować, czy ASLR i inne mechanizmy ochrony pamięci są aktywne.
- Przeprowadzić inwentaryzację ekspozycji usług oraz zależnych aplikacji.
- Odtworzyć konfiguracje na środowiskach testowych w celu oceny realnej podatności.
Podsumowanie
CVE-2026-42945 to poważna luka w NGINX, która łączy szeroki zakres dotkniętych wersji z praktycznymi oznakami aktywnego wykorzystania. Najbardziej prawdopodobnym skutkiem ataku pozostaje destabilizacja pracy serwera poprzez awarie workerów, jednak w określonych warunkach technicznych nie można ignorować również ryzyka zdalnego wykonania kodu.
Dla organizacji wykorzystujących NGINX na brzegu infrastruktury jest to podatność wymagająca pilnej reakcji. Szybkie łatanie, przegląd konfiguracji rewrite, wzmocnienie monitoringu oraz potwierdzenie aktywności mechanizmów hardeningu powinny znaleźć się wysoko na liście działań operacyjnych.