NGINX Rift: krytyczna luka w module rewrite ujawnia 18-letni problem w NGINX - Security Bez Tabu

NGINX Rift: krytyczna luka w module rewrite ujawnia 18-letni problem w NGINX

Cybersecurity news

Wprowadzenie do problemu / definicja

NGINX Rift to krytyczna podatność typu heap-based buffer overflow oznaczona jako CVE-2026-42945. Luka dotyczy sposobu przetwarzania reguł rewrite w module ngx_http_rewrite_module i może prowadzić do zdalnego wykonania kodu lub destabilizacji procesów roboczych serwera.

Problem jest szczególnie istotny, ponieważ NGINX od lat stanowi fundament wielu środowisk webowych, reverse proxy, load balancerów oraz kontrolerów ingress. W efekcie nawet pojedyncza wada w tej warstwie może mieć szeroki wpływ na bezpieczeństwo i dostępność usług.

W skrócie

  • Podatność otrzymała oznaczenie CVE-2026-42945.
  • Jest to krytyczny błąd pamięci typu heap overflow w module rewrite.
  • Warunkiem wyzwolenia jest określona kombinacja reguł rewrite i nienazwanych grup przechwytujących, takich jak $1 lub $2.
  • Atak można przeprowadzić zdalnie, bez uwierzytelnienia, przez odpowiednio przygotowane żądanie HTTP.
  • Skutkiem może być awaria workerów, pętla crash-loop, a w sprzyjających warunkach także zdalne wykonanie kodu.

Kontekst / historia

Ujawniona podatność ma wyjątkowo niepokojący charakter, ponieważ jej źródło znajdowało się w kodzie obecnym od około 18 lat. Oznacza to, że problem przez długi czas pozostawał niewidoczny w jednym z najczęściej wdrażanych komponentów infrastruktury internetowej.

Zakres narażonych wersji jest szeroki. Według ujawnionych informacji problem obejmuje NGINX Open Source od 0.6.27 do 1.30.0 oraz NGINX Plus od R32 do R36. Luka dotyczy także wybranych rozwiązań pochodnych opartych na tym stosie, co zwiększa jej potencjalny zasięg w środowiskach produkcyjnych.

Znaczenie tej luki wynika również z miejsca jej występowania. Nie dotyczy ona niszowego rozszerzenia, ale modułu obecnego w standardowych kompilacjach NGINX, przez co może wystąpić w bardzo wielu realnych wdrożeniach.

Analiza techniczna

Źródłem błędu jest niespójność pomiędzy obliczaniem rozmiaru bufora docelowego a rzeczywistym kopiowaniem danych podczas przetwarzania reguł rewrite. W określonym scenariuszu znak zapytania w ciągu zastępczym aktywuje wewnętrzną logikę obsługi argumentów URI, ale późniejsze wyliczenie długości nie uwzględnia w pełni skutków escapingu danych.

W praktyce oznacza to, że serwer może oszacować potrzebny rozmiar bufora na podstawie „surowej” długości przechwyconych danych, natomiast przy zapisie wykorzystać już postać rozszerzoną o dodatkowe znaki wynikające z transformacji. Jeśli wejściowy URI zawiera znaki zwiększające długość końcowego ciągu, dochodzi do zapisu poza przydzielonym obszarem pamięci sterty.

Istotne jest, że nadpisywane dane mogą być pochodną wejścia kontrolowanego przez atakującego. To zwiększa praktyczne ryzyko eksploatacji, ponieważ uszkodzenie pamięci nie ma wyłącznie losowego charakteru i może zostać częściowo ukształtowane przez odpowiednio przygotowane żądanie HTTP.

Luka jest osiągalna z poziomu publicznego interfejsu sieciowego i nie wymaga wcześniejszego dostępu do systemu. W środowiskach brzegowych, gdzie jeden serwer NGINX obsługuje wiele aplikacji, pojedyncza błędna konfiguracja może przełożyć się na ryzyko dla wielu usług jednocześnie.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest możliwość zdalnego wykonania kodu w kontekście procesu workera NGINX. Nawet jeśli pełna eksploatacja nie będzie możliwa w każdej konfiguracji, sam potencjał wymuszania awarii workerów oznacza realne zagrożenie dla dostępności aplikacji.

Ryzyko jest szczególnie wysokie w organizacjach, które:

  • wystawiają NGINX bezpośrednio do Internetu,
  • korzystają z rozbudowanych reguł rewrite,
  • utrzymują wiele aplikacji za jedną instancją proxy,
  • używają produktów pochodnych opartych na NGINX,
  • mają opóźniony proces aktualizacji komponentów infrastrukturalnych.

Brak potwierdzonej aktywnej eksploatacji w chwili ujawnienia nie oznacza niskiego priorytetu. Publiczne opisanie warunków wyzwolenia oraz dostępność poprawek zwykle szybko prowadzą do powstania skanerów i prób automatycznego wykorzystywania podatności przeciwko niezałatanym systemom.

Rekomendacje

Najważniejszym krokiem jest szybka aktualizacja do wersji naprawionych. Dla NGINX Open Source wskazano wydania 1.30.1 oraz 1.31.0, natomiast dla NGINX Plus odpowiednie poprawki obejmują R36 P4 oraz R32 P6.

Jeżeli natychmiastowe wdrożenie aktualizacji nie jest możliwe, należy zastosować obejście konfiguracyjne. Kluczowe jest zastąpienie nienazwanych grup przechwytujących, takich jak $1 i $2, grupami nazwanymi we wszystkich podatnych regułach rewrite.

Warto również przeprowadzić przegląd konfiguracji pod kątem współwystępowania następujących elementów:

  • dyrektywy rewrite z nienazwanymi grupami przechwytującymi,
  • znaku ? w ciągu zastępczym,
  • kolejnych dyrektyw rewrite, if lub set w tym samym zakresie konfiguracji.

Z perspektywy operacyjnej zalecane są także dodatkowe działania obronne:

  • audyt wszystkich plików konfiguracyjnych NGINX i rozwiązań pochodnych,
  • weryfikacja wersji kontrolerów ingress, WAF-ów i modułów bezpieczeństwa,
  • monitorowanie logów błędów oraz nietypowych restartów workerów,
  • analiza podejrzanych żądań zawierających nietypowe znaki w URI,
  • uwzględnienie tej podatności w działaniach threat hunting i skanowaniu ekspozycji zewnętrznej.

Podsumowanie

NGINX Rift pokazuje, że nawet dojrzałe i powszechnie stosowane komponenty infrastrukturalne mogą zawierać wieloletnie błędy o krytycznym znaczeniu. CVE-2026-42945 łączy zdalną osiągalność, brak potrzeby uwierzytelnienia, możliwość kontrolowanego uszkodzenia pamięci oraz szeroki potencjalny zasięg operacyjny.

Dla zespołów bezpieczeństwa i administratorów priorytetem powinny być szybka identyfikacja podatnych instancji, aktualizacja do wersji naprawionych oraz przegląd reguł rewrite pod kątem wzorca wyzwalającego problem. Zwłoka w reakcji może oznaczać zarówno ryzyko przejęcia procesu, jak i poważne zakłócenia dostępności usług.

Źródła

  1. Security Affairs — https://securityaffairs.com/192132/hacking/nginx-rift-an-18-year-old-flaw-in-the-worlds-most-deployed-web-server-just-came-to-light.html
  2. depthfirst — NGINX Rift — https://depthfirst.com/nginx-rift
  3. NVD — CVE-2026-42945 — https://nvd.nist.gov/vuln/detail/CVE-2026-42945
  4. F5 Security Advisory K000161019 — https://my.f5.com/manage/s/article/K000161019