18-letnia luka w NGINX zagraża serwerom. Administratorzy muszą działać szybko
Krytyczna podatność CVE-2026-42945 w serwerze NGINX umożliwia ataki DoS i potencjalnie zdalne wykonanie kodu. Luka istnieje w kodzie od 18 lat i dotyczy milionów serwerów na całym świecie, w tym w Polsce. Administratorzy powinni niezwłocznie zastosować dostępne łatki.
Badacze z firmy DepthFirst AI odkryli 18-letnią lukę w serwerze NGINX, która może prowadzić do odmowy usługi, a w sprzyjających warunkach – do zdalnego wykonania kodu. Podatność oznaczona jako CVE-2026-42945 otrzymała krytyczną ocenę 9.2 w skali CVSS. Problem dotyczy szerokiego spektrum wersji i konfiguracji, a administratorzy w Polsce powinni jak najszybciej sprawdzić, czy ich serwery są narażone.
Co się stało i kogo dotyczy
Luka CVE-2026-42945 to przepełnienie bufora sterty w module ngx_http_rewrite_module. Występuje w wersjach NGINX Open Source od 0.6.27 do 1.30.0 włącznie. Jak podaje BleepingComputer, podatność można wykorzystać, gdy konfiguracja NGINX zawiera jednocześnie dyrektywy 'rewrite’ i 'set’ – wzorzec powszechny w bramkach API i konfiguracjach reverse proxy.
NGINX to jeden z najpopularniejszych serwerów internetowych. Według danych cytowanych w artykule, obsługuje około jednej trzeciej największych stron internetowych. Korzystają z niego dostawcy chmur, banki, platformy e-commerce, media oraz klastry Kubernetes. Zatem skala potencjalnego zagrożenia jest ogromna.
DepthFirst AI odkryło również trzy inne luki w NGINX o średnim poziomie ryzyka: CVE-2026-42946 (nadmierna alokacja pamięci w modułach SCGI/UWSGI), CVE-2026-40701 (use-after-free w asynchronicznym rozwiązywaniu DNS OCSP) oraz CVE-2026-42934 (błąd parsowania UTF-8 prowadzący do odczytu poza zakresem).
Jak działa luka i jakie niesie ryzyko
Mechanizm podatności wynika z niespójnego przetwarzania stanu w wewnętrznym silniku skryptów NGINX. Silnik wykonuje przepisywanie adresów URL w dwóch przejściach: najpierw oblicza potrzebną pamięć, potem kopiuje dane. Flaga 'is_args’ pozostaje ustawiona po przepisaniu zawierającym znak ’?’, przez co NGINX oblicza rozmiar bufora na podstawie nieskapowanych długości URI, a następnie zapisuje większe dane po escapowaniu (np. znaki '+’ i '&’). Skutkuje to przepełnieniem bufora sterty.
Badacze zademonstrowali zdalne wykonanie kodu na systemie z wyłączoną ochroną ASLR (Address Space Layout Randomization). Zauważają, że architektura wieloprocesowa NGINX ułatwia eksploatację, ponieważ procesy robocze dziedziczą niemal identyczne układy pamięci po procesie głównym. „Jeśli nasz exploit zawiedzie i spowoduje awarię procesu roboczego, proces główny po prostu tworzy nowy z dokładnie tym samym układem pamięci” – wyjaśniają badacze DepthFirst w rozmowie z BleepingComputer. „Teoretycznie moglibyśmy wykorzystać ten projekt do wycieku ASLR poprzez stopniowe nadpisywanie wskaźników bajt po bajcie”.
Realne ryzyko zdalnego wykonania kodu w typowych, zabezpieczonych środowiskach jest jednak ograniczone. Ekspert Kevin Beaumont zwrócił uwagę, że exploit wymaga specyficznej konfiguracji NGINX, znajomości podatnego punktu końcowego, a dowód koncepcji został przetestowany z wyłączonym ASLR. Podobną ocenę przedstawili maintainerzy AlmaLinux, którzy po niezależnym odtworzeniu luki potwierdzili, że wywołanie awarii procesu roboczego jest trywialne i niezawodne, ale przekształcenie przepełnienia sterty w wiarygodne zdalne wykonanie kodu na systemach z włączonym ASLR „nie jest trywialne”. Jednocześnie AlmaLinux ostrzegł, że „niełatwe” nie oznacza niemożliwe, a samo ryzyko DoS jest wystarczającym powodem do pilnej reakcji.
Które wersje są zagrożone i jakie są dostępne łatki
Podatność została zgłoszona producentowi 21 kwietnia 2026 roku. F5, właściciel NGINX, opublikował biuletyn bezpieczeństwa, w którym wymienił zagrożone produkty:
- NGINX Open Source wersje 0.6.27 – 1.30.0
- NGINX Plus R32 – R36
- NGINX Instance Manager 2.16.0 – 2.21.1
- F5 WAF for NGINX 5.9.0 – 5.12.1
- NGINX App Protect WAF 4.9.0 – 4.16.0 i 5.1.0 – 5.8.0
- F5 DoS for NGINX 4.8.0
- NGINX App Protect DoS 4.3.0 – 4.7.0
- NGINX Gateway Fabric 1.3.0 – 1.6.2 i 2.0.0 – 2.5.1
- NGINX Ingress Controller 3.5.0 – 3.7.2, 4.0.0 – 4.0.1 i 5.0.0 – 5.4.1
Poprawki zostały udostępnione w wersjach NGINX Open Source 1.31.0 i 1.30.1, NGINX Plus R36 P4 oraz NGINX Plus R32 P6. Dla administratorów, którzy nie mogą natychmiast zaktualizować, F5 zaleca tymczasowe zastąpienie nienazwanych grup przechwytywania PCRE ($1, $2 itd.) w podatnych regułach 'rewrite’ nazwanymi grupami przechwytywania, co eliminuje główny warunek wstępny eksploatacji.
Co powinni zrobić administratorzy w Polsce
Działanie w pierwszej kolejności: sprawdzić wersję NGINX i zastosować dostępne łatki. Proces aktualizacji należy przeprowadzić zgodnie z procedurami bezpieczeństwa, najlepiej w oknie konserwacji. Jeśli natychmiastowa aktualizacja nie jest możliwa, wdrożyć tymczasowe mitygacje zalecane przez F5.
Należy również przejrzeć konfiguracje NGINX pod kątem obecności dyrektyw 'rewrite’ i 'set’ używanych razem. W miarę możliwości można rozważyć przepisanie reguł z użyciem nazwanych grup przechwytywania. Administratorzy powinni też monitorować komunikaty producenta oraz biuletyny bezpieczeństwa, takie jak te publikowane przez CERT Polska, który regularnie ostrzega przed krytycznymi podatnościami.
Dla zespołów IT w firmach korzystających z NGINX w środowiskach produkcyjnych kluczowe jest opracowanie planu priorytetyzacji poprawek. Jak podkreśla w swoim newsletterze Martin Lee z Cisco Talos, nadchodzi czas wzmożonego łatania – narzędzia AI coraz skuteczniej znajdują błędy w oprogramowaniu, co zwiększy liczbę publikowanych poprawek. „Bez odpowiedniego planowania liczba poprawek może przewyższyć możliwości organizacji w zakresie ich wdrażania” – ostrzega Lee.
W przypadku wykrycia prób eksploatacji lub nietypowej aktywności na serwerach NGINX należy niezwłocznie skontaktować się z zespołem CERT Polska lub innym właściwym zespołem reagowania na incydenty bezpieczeństwa komputerowego.
Co dalej
Odkrycie luki CVE-2026-42945 pokazuje, jak długo mogą pozostawać niezauważone błędy w powszechnie używanym oprogramowaniu. DepthFirst AI wykorzystało zautomatyzowany system skanowania, który w ciągu sześciu godzin znalazł cztery podatności. To potwierdza trend opisywany przez ekspertów: narzędzia AI do wykrywania luk stają się coraz skuteczniejsze, co w krótkim okresie przełoży się na większą liczbę publikowanych poprawek. Administratorzy powinni przygotować swoje organizacje na to wyzwanie, usprawniając procesy zarządzania łatami i testowania aktualizacji.
W przypadku NGINX kluczowe jest jak najszybsze zastosowanie poprawek, szczególnie że atak DoS jest łatwy do przeprowadzenia. Choć zdalne wykonanie kodu w typowych warunkach jest trudne, ryzyko nie jest zerowe, a konsekwencje potencjalnego przejęcia serwera byłyby poważne. Działajmy odpowiedzialnie – aktualizujmy, testujmy i monitorujmy.
