15 lipca pojawiła się poprawka do kodu z 2011 roku

15 lipca 2026 roku projekt nginx wydał wersje 1.30.4 oraz 1.31.3, a to wydanie zamknęło przepełnienie sterty osiągalne w każdej wersji aż do 0.9.6. Tamta wersja pochodzi z 2011 roku. Podatność jest zarejestrowana jako CVE-2026-42533 i oceniona na 9,2 w skali CVSS w wersji 4.0. Firma F5 opublikowała zalecenie K000162097 dla klientów NGINX Plus, naprawione w 37.0.3.1.

Lista zgłaszających jest nietypowa. Ponad tuzin badaczy zgłosiło ten sam problem niezależnie od siebie, wśród nich Mufeed VH z Winfunc Research, a wieloletni opiekun projektu Maxim Dounin zajął się poprawką. Kiedy lukę znajduje tylu ludzi naraz, rozsądne jest założenie, że nie była trudna do znalezienia i że inni znaleźli ją bez składania jakiegokolwiek zgłoszenia.

Co musi być w konfiguracji, żeby to miało znaczenie

Błąd tkwi w silniku skryptowym, który ocenia wyrażenia tekstowe budowane przez nginx w chwili obsługi żądania. Ta ocena przebiega w dwóch przebiegach. Pierwszy mierzy, jak duży musi być bufor, korzystając ze stanu przechwyceń w tamtym momencie. Drugi zapisuje do tego bufora dane przechwyceń, na które żądanie może wpłynąć. Tam, gdzie oba przebiegi się rozchodzą, zapis jest większy niż zarezerwowane miejsce.

Wyzwalacz jest węższy, niż sugeruje zakres wersji. Potrzebna jest dyrektywa map oparta na wyrażeniu regularnym, której zmienna wyjściowa jest przywoływana w wyrażeniu tekstowym po przechwyceniu z wcześniejszego dopasowania, czyli numerowane przechwycenia zapisywane jako dolar-jeden i dolar-dwa. Jeśli twoja konfiguracja nie zawiera mapy o takiej postaci, sam numer wersji nie umieszcza cię w gronie dotkniętych. To najbardziej użyteczny fakt w całej publikacji.

Bez uwierzytelnienia, ale jeszcze bez broni

Tam, gdzie wzorzec występuje, żądanie, które go wyzwala, nie potrzebuje żadnych poświadczeń. Wystarczy spreparowane żądanie HTTP z dowolnego miejsca w internecie. Pewnym skutkiem jest awaria i ponowne uruchomienie procesu roboczego, czyli odmowa usługi przed frontowymi drzwiami tego, co serwer publikuje. Zdalne wykonanie kodu to przypadek trudniejszy, możliwy tam, gdzie losowanie przestrzeni adresowej jest wyłączone lub daje się obejść, a badacz Stan Shaw twierdzi, że luka sama dostarcza drogę wokół tego zabezpieczenia.

Na 20 lipca nie ma publicznego kodu ataku, a CVE nie figuruje w amerykańskim katalogu znanych wykorzystywanych podatności. To stan obecny, a nie prognoza. Shaw zapowiedział publikację dowodu koncepcji 21 dni po ukazaniu się poprawki, co umieszcza ją w pierwszym tygodniu sierpnia. Niewykorzystywana krytyczna podatność z opublikowaną datą to inny problem planistyczny niż taka bez daty.

Trzy przepełnienia w jednym podsystemie w dwa miesiące

CVE-2026-42533 nie jest odosobnionym znaleziskiem. To trzecie przepełnienie sterty ujawnione w kodzie oceniającym wyrażenia w nginx w ciągu około dwóch miesięcy, po CVE-2026-42945 z maja i CVE-2026-9256 wkrótce potem. Trzy znaleziska w jednym podsystemie w jednym kwartale to wzorzec, a nie przypadek, a ten wzorzec mówi, że konstrukcja dwuprzebiegowa jest właśnie przeczesywana przez ludzi, którzy już wiedzą, gdzie szukać.

Konsekwencja dla planowania jest jednoznaczna. Kto potraktuje to jako pojedynczy skok wersji i pójdzie dalej, ma wyraźnie różne od zera prawdopodobieństwo, że wróci tu w tym samym kwartale. Na liście obserwacyjnej powinien znaleźć się podsystem, a nie numer CVE, a trwale zmniejszyć da się te postacie konfiguracji, które do niego docierają.

Sprawdzenie, zanim zadzwonisz do dostawcy

Większość krytycznych publikacji o serwerach WWW pozostawia właściciela firmy zależnym od innych. Ta nie, ponieważ wyzwalacz da się odczytać w pliku, który możesz otworzyć. Poproś o swoją wersję nginx, a potem zapytaj, czy któryś blok map w konfiguracji używa wyrażenia regularnego i zasila zmienną łączoną później w tekst obok numerowanych przechwyceń. Dwa pytania, jedna odpowiedź i wiesz, czy początek sierpnia to termin, czy tylko notatka.

Dla firm objętych dyrektywą w sprawie bezpieczeństwa sieci i systemów informatycznych w Unii Europejskiej, a także dla tych, które stosują równoważne wytyczne brytyjskie, dokumentacja waży tyle samo co poprawka. Zapisz, na jakiej wersji byłeś, kiedy sprawdziłeś konfigurację i jakie obejście zastosowałeś. Organ nadzoru pytający o krytyczną podatność opublikowaną w lipcu będzie chciał datę twojej oceny, a nie tylko datę późniejszej aktualizacji.

Czytaj dalej: Cztery agenty kodu wyszły, nic nie łamiąc  |  ServiceNow naprawił najpierw własną chmurę, klientów self-hosted 103 dni później