В NGINX обнаружили 18-летний баг, которому присвоили CVE-2026-42945 и критичность 9,2 балла по CVSS. Эта уязвимость NGINX позволяет надежно уронить worker-процессы сервера, а при специфической конфигурации и ослабленной защите памяти теоретически довести атаку до удаленного выполнения кода. Для команд, у которых NGINX работает как фронт для API, балансировщик или ingress в Kubernetes, новость неприятная: проблема не в экзотическом модуле, а в очень старом и довольно обычном сценарии с rewrite-правилами.
Об инциденте сообщает BleepingComputer со ссылкой на исследователей из DepthFirst AI и advisory от F5. По их данным, баг жил в коде примерно с 2008 года и затрагивает open-source NGINX версий 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 и 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 и 2.0.0-2.5.1, а также NGINX Ingress Controller 3.5.0-3.7.2, 4.0.0-4.0.1 и 5.0.0-5.4.1. Исправления уже выпущены в NGINX Open Source 1.31.0 и 1.30.1, а для коммерческих сборок — в NGINX Plus R36 P4 и R32 P6.
Корень проблемы — в модуле ngx_http_rewrite_module, точнее, в переполнении буфера в куче. Если конфигурация использует одновременно директивы rewrite и set, внутренний движок скриптов NGINX сначала считает, сколько памяти нужно под результат, а потом копирует данные. В одном из сценариев флаг is_args после rewrite c символом ? остается в неверном состоянии. На этапе расчета берется длина неэкранированного URI, а на этапе записи в буфер попадают уже экранированные данные, которые могут оказаться длиннее — например, из-за символов вроде + и &. Разница кажется мелочью ровно до того момента, пока не начинается порча памяти. В терминах эксплуатации это не «смешной edge case», а вполне понятная точка входа для переполнения heap.
Исследователи утверждают, что смогли добиться неаутентифицированного выполнения кода через специально подготовленные HTTP-запросы: повредить соседние структуры memory pool, переписать указатели на cleanup-handler, «засеять» память поддельными структурами через тела POST-запросов и в нужный момент заставить NGINX вызвать system() при очистке пула. Но здесь начинается важная часть, которую обычно прячут под громкий заголовок про RCE. Их proof-of-concept сработал на системе, где была отключена ASLR — защита от атак на память. По умолчанию она включена, хотя в отдельных средах, включая некоторые embedded-системы и анализаторские виртуалки, ее действительно могут выключать ради производительности или удобства. DepthFirst также указывает, что многопроцессная архитектура NGINX помогает атакующему: если worker падает, master поднимает новый с почти тем же расположением памяти, так что попытки можно повторять до удачного результата.
Кроме главной находки, за ту же шестичасовую сессию автономного сканирования исследователи подняли еще три проблемы с повреждением памяти. Это CVE-2026-42946 — чрезмерное выделение памяти в модулях SCGI/UWSGI с возможными аллокациями порядка 1 ТБ и падением worker-процессов; CVE-2026-40701 — use-after-free в асинхронной обработке OCSP DNS resolution; и CVE-2026-42934 — off-by-one ошибка в UTF-8 parsing с чтением за границами памяти. В исходном материале говорится, что три дополнительных дефекта получили средний уровень серьезности, хотя для CVE-2026-42946 отдельно упоминается высокий severity. Это не меняет главного вывода: автоматизированный поиск багов, особенно с AI-компонентом, все чаще находит не логические шероховатости, а очень приземленные memory corruption у зрелых инфраструктурных проектов. И да, «проекту почти два десятка лет, значит все уже нашли» больше не работает.
При этом вокруг реальной эксплуатируемости CVE-2026-42945 уже начался нормальный профессиональный спор, и он полезнее хайпа. Исследователь Кевин Бомонт обратил внимание, что для атаки нужен не просто уязвимый NGINX, а подходящая конфигурация с конкретными паттернами rewrite, плюс злоумышленнику надо найти нужную конечную точку, а опубликованный RCE PoC тестировался на заведомо уязвимой среде с отключенной ASLR. AlmaLinux после собственного воспроизведения пришла к схожему выводу: положить worker crafted-запросом действительно просто и надежно, то есть DoS-риски реальны, а вот превратить heap overflow в стабильный удаленный захват на системе с включенной ASLR «нетривиально». Для бизнеса это, впрочем, слабое утешение. Если внешний NGINX можно стабильно ронять без аутентификации, то у вас уже инцидент, а не академическая дискуссия о красоте эксплуатации.
Практический вывод здесь достаточно скучный, а значит полезный. Если вы используете уязвимые версии, обновляться нужно до 1.31.0 или 1.30.1, а на коммерческих сборках — до рекомендованных патч-релизов F5. Если обновление быстро не проходит, временная мера от вендора такая: заменить безымянные PCRE-группы захвата $1, $2 и так далее в уязвимых правилах rewrite на именованные captures. Это убирает ключевое условие эксплуатации. Для команд эксплуатации и DevOps список действий тоже очевиден: проверить конфиги на сочетание rewrite и set, пересмотреть ingress-шаблоны и правила API gateway, убедиться, что ASLR нигде не отключена без очень веской причины, и отдельно прогнать негативные тесты на отказоустойчивость. История неприятна именно тем, что уязвимость NGINX пряталась не в редком расширении, а в логике, которая у многих живет годами по принципу «не трогай, оно проксирует».
Вся эта история бьет не только по NGINX, но и по привычке индустрии считать зрелую инфраструктуру «проверенной временем». Похоже, ближайшие годы пройдут под знаком массовой доинвентаризации старого кода с помощью автономных систем анализа: баги, которые раньше лежали десятилетиями, теперь будут поднимать пачками за несколько часов. Для open-source это одновременно хорошая и очень раздражающая новость: чинить придется быстрее, чем успевает родиться очередная легенда о «легендарной стабильности» сетевого софта. Подробнее об исходной публикации — BleepingComputer .
The post В NGINX нашли 18-летнюю уязвимость с DoS и риском RCE appeared first on iTech News.