NGINX Rift: AI znalazł go w sześć godzin. Człowiek nie znalazł przez osiemnaście lat.

Zaktualizuj nginx teraz. Wersje 1.30.1 i 1.31.0 zawierają łatkę. Dotyczy każdej wersji od 0.6.27 (2008) do 1.30.0 włącznie — czyli praktycznie każdego nginx wdrożonego przed tygodniem. Publiczny PoC jest już na GitHubie. Automatyczne skanery indeksują podatne endpointy od wczoraj.

Jeśli nie możesz zaktualizować natychmiast: zastąp nazwane przechwytywania $1, $2 w dyrektywach rewrite nazwanymi przechwytywaniami ((?P<name>...)) wszędzie gdzie po rewrite następuje set lub if. To eliminuje warunek wyzwalający podatność bez aktualizacji.

W połowie maja 2026 roku firma depthfirst uruchomiła swój system autonomicznej analizy kodu na bazie kodu nginx. Po sześciu godzinach system zwrócił cztery raporty o błędach korupcji pamięci. Jeden z nich był krytyczny.

Błąd siedział tam od 2008 roku. Osiemnaście lat audytów bezpieczeństwa, fuzzingu, code review, tysiące oczu patrzących na jeden z najszerzej wdrożonych serwerów webowych na świecie — i żadne z nich go nie znalazło. Autonomiczny system AI znalazł go w sześć godzin.

Jeden dzień wcześniej GTIG udokumentował pierwszego AI zero-daya w rękach atakujących — cyberprzestępcy używający AI do znalezienia i wyeksploitowania nieznanej podatności w planowanej masowej kampanii. Teraz ta sama klasa narzędzi, po stronie obrońców, właśnie wyciągnęła osiemnastoletni błąd z kodu który napędza około jednej trzeciej ruchu webowego na świecie.

Dwa dni, dwie strony tej samej zmiany.

Jak działa błąd

CVE-2026-42945, nazwany NGINX Rift, siedzi w ngx_http_rewrite_module — silniku przekierowań URL i przypisań zmiennych, używanym w praktycznie każdym wdrożeniu nginx.

Silnik ten przetwarza dyrektywy w dwóch przejściach: pierwsze oblicza rozmiar potrzebnej pamięci, drugie zapisuje dane do zaalokowanego bufora. Problem pojawia się gdy konfiguracja łączy dyrektywę rewrite zawierającą pytajnik z następującą po niej dyrektywą set lub if. W tym specyficznym układzie pierwsze przejście błędnie oblicza rozmiar bufora dla sekwencji ucieczki argumentów — i drugie przejście zapisuje więcej danych niż zaalokowano.

Depthfirst opisuje efekt operacyjny bez owijania w bawełnę: "Atakujący który może dotrzeć do podatnego serwera nginx przez HTTP może wysłać jedno żądanie które przepełni heap w procesie worker i osiągnie zdalne wykonanie kodu. Nie ma kroku uwierzytelnienia, żadnego wymagania wcześniejszego dostępu, żadnej potrzeby istniejącej sesji."

Warunek: ASLR wyłączone lub słabe. W systemach z ASLR włączonym worst case to crash workera — co w konfiguracji z jednym workerem oznacza pełny DoS, w konfiguracji wieloworkerowej tymczasową niedostępność. Depthfirst opisuje teoretyczną ścieżkę do obejścia ASLR przez stopniowe nadpisywanie wskaźników heap przez wielokrotne żądania — ale pracujące PoC wymaga wyłączonego ASLR.

Praktyczna ocena: na zahardowanych systemach produkcyjnych z ASLR — ryzyko DoS. Na embedded, legacy lub mniej restrykcyjnych środowiskach — ryzyko RCE. Scenariusz CI/CD, środowisk testowych, obrazów kontenerowych bez pełnego hardeningu — podwyższony.

Dlaczego nikt tego nie znalazł

Jest naturalne pytanie: jak to możliwe że taki błąd przeżył osiemnaście lat w jednym z najważniejszych projektów open source na świecie?

Odpowiedź leży nie w zaniedbaniu ale w tym jakiego rodzaju błąd to jest. Root cause jest trójdzielny: flaga is_args w stanie silnika skryptów, logika obliczania rozmiaru bufora w handlerze dyrektywy set, i rozszerzenie escape w ścieżce kodowania argumentów — każdy z tych elementów jest z osobna czytelny i poprawny. Dopiero ich kombinacja w konkretnym układzie dyrektyw tworzy błąd.

Klasyczne narzędzia bezpieczeństwa — fuzzery, statyczne analizatory kodu, skanery podatności — są zoptymalizowane pod kątem konkretnych wzorców: przepełnień buforów gdzie dane wyjściowe są bezpośrednio kontrolowane, use-after-free gdzie wskaźnik jest reużywany po zwolnieniu, format string bugs. Szukają znanych klas błędów w znanych miejscach.

Błąd w NGINX Rift wymagał rozumienia kontekstu: jak te trzy komponenty wchodzą ze sobą w interakcję przy konkretnej konfiguracji, co oznacza rozbieżność między tym co silnik oblicza a tym co zapisuje. To jest dokładnie ta klasa "semantycznych błędów logicznych" które GTIG opisywał wczoraj jako nową specjalność modeli językowych: "LLMs excel at identifying these types of high-level flaws... effectively reading the developer's intent to correlate the logic with the contradictions of its hardcoded exceptions."

Pisaliśmy o trzynastoletnim błędzie w Apache ActiveMQ znalezionym przez Claude — badacz który powiedział "80% Claude, 20% człowieka." Tam AI był narzędziem w rękach człowieka. Tutaj system depthfirst działał autonomicznie, bez ludzkiej interwencji w fazie odkrywania. Sześć godzin, cztery błędy, jeden krytyczny.

Skala

Nginx napędza około jednej trzeciej wszystkich stron internetowych na świecie. Za każdą z nich stoi jakaś wersja nginx — i każda wersja między 0.6.27 a 1.30.0 jest podatna.

Podatne są: NGINX Open Source od 0.6.27 do 1.30.0, NGINX Plus R32–R36, NGINX Instance Manager 2.16.0–2.21.1, NGINX App Protect WAF 4.9.0–5.8.0, NGINX Gateway Fabric 1.4.0–1.7.0, NGINX Ingress Controller 3.5.0–5.4.1.

Warunek konfiguracyjny który aktywuje podatność — rewrite z pytajnikiem przed set lub if — jest "common pattern in API gateway setups" według opisu depthfirst. API gateway to infrastruktura stojąca przed każdym nowoczesnym backendem. To nie jest egzotyczna konfiguracja, to jest standardowa.

Dwa dni, dwa kierunki

Warto zestawić te dwa zdarzenia wprost, bo razem opisują coś ważniejszego niż każde z osobna.

11 maja: GTIG dokumentuje pierwszego AI zero-daya. Atakujący używają AI żeby znaleźć i wyeksploitować nieznaną podatność w planowanej masowej kampanii. Model czyta intencję dewelopera i znajduje sprzeczność między projektem a implementacją.

13 maja: depthfirst publikuje NGINX Rift. AI autonomicznie znajdując osiemnastoletni błąd w sześciu godzinach. Ten sam rodzaj rozumowania, ta sama klasa odkrycia — po stronie obrońców.

Przez ostatnie miesiące cyberflux opisywał ten wyścig z różnych perspektyw — Mythos Preview, GPT-5.4-Cyber, CNBC "hysteria czy diagnoza", M-Trends 2026 z ujemną medianą time-to-exploit. Wszystkie te analizy opisywały potencjał lub trend.

NGINX Rift i wczorajszy raport GTIG to już nie trend. To są dwa konkretne przypadki z tej samej tygodnia, po obu stronach tej samej technologii.

Pisaliśmy przy okazji raportu GTIG że Hultquist mówi o "dla każdego zero-daya który możemy powiązać z AI, prawdopodobnie jest ich wiele więcej." Depthfirst pokazuje symetryczny wniosek dla strony defensywnej: dla każdego błędu który AI znalazło i opublikowano, prawdopodobnie jest ich wiele więcej — znalezionych przez organizacje które nie publikują, przez systemy które działają cicho w tle, przez zespoły badawcze które właśnie zaczynają stosować te same metody.

Dziura w nginx z 2008 roku nie była ukryta dlatego że była trudna do znalezienia odpowiednimi narzędziami. Była ukryta dlatego że odpowiednie narzędzia nie istniały do 2026 roku.

Źródła

The Hacker News — szczegóły techniczne i opisy CVE: https://thehackernews.com/2026/05/18-year-old-nginx-rewrite-module-flaw.html

GBHackers — autonomiczne odkrycie przez AI i exploit chain: https://gbhackers.com/poc-released-for-18-year-old-nginx-flaw/

Panelica Blog — analiza co RCE jako www-data faktycznie oznacza i jaka jest praktyczna ekspozycja: https://panelica.com/blog/nginx-cve-2026-42945-fragnesia-cve-2026-46300-panelica-isolation

SOCRadar — ASLR i realna ocena ryzyka DoS vs RCE: https://socradar.io/blog/cve-2026-42945-nginx-rewrite-heap-overflow-dos-rce/

F5 Security Advisory — oficjalne advisory z listą dotkniętych produktów: https://my.f5.com/manage/s/article/K000150757

Threat Landscape Blog — TTP matrix i exploit chain depthfirst: https://threatlandscape.io/blog/nginx-rift-cve-2026-42945-critical-rce-vulnerability