Krytyczna luka w NGINX – opublikowano kod exploita. Administratorzy powinni działać

Firma F5 załatała w tym tygodniu krytyczną podatność w serwerze NGINX, która otrzymała oznaczenie CVE-2026-42945 i ocenę 9.2 w skali CVSS. Problem istnieje od 16 lat i dotyczy zarówno płatnej wersji NGINX Plus, jak i darmowej edycji open source. Co gorsza, w sieci pojawiły się już szczegóły techniczne oraz kod dowodu koncepcji (PoC) dla tej luki, co znacznie zwiększa ryzyko ataków.

Na czym polega podatność?

Luka ma charakter przepełnienia bufora sterty (heap buffer overflow) w komponencie ngx_http_rewrite_module. Jak wyjaśniają badacze z firmy Depthfirst, problem wynika z dwuprzebiegowego procesu w silniku skryptów NGINX: pierwszy przebieg oblicza wymagany rozmiar bufora, drugi kopiuje dane. Jeśli w zastąpieniu reguły przepisywania (rewrite replacement) pojawi się znak zapytania („?”), niepropagowana flaga powoduje alokację zbyt małego bufora. W efekcie dane URI, które atakujący może kontrolować, są zapisywane poza przydzielonym obszarem pamięci.

„Dodając do URI znaki plus, możemy wymusić na funkcji escapującej rozszerzenie każdego bajtu na trzy bajty, co powoduje przepełnienie przydzielonego bloku. Rozmiar przepełnienia jest całkowicie pod naszą kontrolą – zależy od liczby dostarczonych znaków podlegających escapowaniu” – opisują badacze w swoim raporcie. Firma F5 ostrzega, że podatność może prowadzić do odmowy usługi (DoS), a w przypadku wyłączenia mechanizmu ASLR (Address Space Layout Randomization) możliwe jest także zdalne wykonanie kodu (RCE).

Kogo dotyczy problem?

Podatność występuje w serwerach NGINX, które używają dyrektyw rewrite i set. Według informacji producenta, luka została załatana w następujących wersjach:

• NGINX Plus – wersje 37.0.0, R36 P4 oraz R32 P6,
• NGINX open source – wersje 1.31.0 oraz 1.30.1.

Wszystkie starsze wersje są podatne na atak. Biorąc pod uwagę, że NGINX jest jednym z najpopularniejszych serwerów WWW na świecie, skala potencjalnego zagrożenia jest znacząca. Administratorzy, którzy jeszcze nie zaktualizowali swoich instalacji, powinni zrobić to niezwłocznie.

Dlaczego to ważne dla polskich użytkowników?

NGINX jest powszechnie stosowany w polskich firmach – zarówno w małych sklepach internetowych, jak i w dużych infrastrukturach korporacyjnych. Często pełni rolę odwrotnego proxy, load balancera lub serwera treści statycznych. Opublikowanie kodu exploita oznacza, że atakujący mogą w krótkim czasie przeprowadzić zautomatyzowane skanowanie internetu w poszukiwaniu podatnych instancji. W przeszłości podobne luki w NGINX były wykorzystywane do przejmowania serwerów, kradzieży danych lub włączania ich do botnetów.

Warto podkreślić, że CVE-2026-42945 nie jest jedyną podatnością, którą F5 załatał w ramach swojego kwartalnego wydania poprawek – łącznie usunięto ponad 50 błędów. Administratorzy powinni zapoznać się z pełną listą zmian i zastosować wszystkie dostępne aktualizacje.

Jak się chronić?

Podstawowym i najskuteczniejszym działaniem jest aktualizacja NGINX do wersji 1.31.0 lub 1.30.1 (w przypadku open source) bądź do wskazanych wersji NGINX Plus. Proces aktualizacji jest dobrze udokumentowany i w większości przypadków nie wymaga przestoju usług, jeśli korzysta się z mechanizmów graceful reload.

Do czasu wdrożenia poprawek warto rozważyć dodatkowe środki ostrożności:

• Ograniczenie dostępu do serwera – jeśli to możliwe, należy zablokować ruch do NGINX z zewnętrznych sieci, pozostawiając dostęp tylko z zaufanych adresów IP.
• Monitorowanie logów – warto sprawdzać logi dostępu pod kątem nietypowych żądań zawierających długie ciągi znaków lub znaki plus.
• Włączenie ASLR – choć nie chroni przed atakiem DoS, utrudnia przeprowadzenie zdalnego wykonania kodu.
• Segmentacja sieci – serwery NGINX powinny znajdować się w wydzielonej strefie DMZ, z ograniczonym dostępem do wewnętrznych zasobów.

W przypadku braku możliwości natychmiastowej aktualizacji, administratorzy mogą rozważyć tymczasowe wyłączenie dyrektyw rewrite i set, jeśli nie są one niezbędne do działania aplikacji. Należy jednak pamiętać, że jest to rozwiązanie doraźne i nie eliminuje całkowicie ryzyka.

Co dalej?

Publikacja kodu PoC dla krytycznej luki w tak popularnym oprogramowaniu jak NGINX to sygnał, że ataki mogą nastąpić w każdej chwili. Historia pokazuje, że czas między ujawnieniem podatności a jej masowym wykorzystaniem stale się skraca. W przypadku CVE-2026-42945 kluczowe jest szybkie działanie – aktualizacja powinna być priorytetem dla każdego administratora serwerów NGINX. Warto także śledzić komunikaty producenta oraz raporty firm bezpieczeństwa, które mogą dostarczyć dodatkowych informacji o ewentualnych atakach w środowisku.