ИИ-агент нашел в NGINX критическую уязвимость, которой 18 лет

Исследователи компании depthfirst запустили свой автономный ИИ-агент на исходный код NGINX — и за 6 часов он нашел критическую уязвимость, которая жила с 2008 года. CVE-2026-42945 с рейтингом 9.2 по шкале CVSS позволяет удаленно выполнять произвольный код через комбинацию директив rewrite и set в конфигурации сервера. На NGINX работает почти треть всех сайтов мира, и под угрозой оказались версии от 0.6.27 до 1.30.0 — то есть почти весь жизненный цикл продукта.

depthfirst — стартап, разрабатывающий автономные системы для аудита низкоуровневого кода. По словам исследователей, запуск сканирования NGINX потребовал одного клика — система сама загрузила репозиторий и проанализировала его. За 6 часов агент нашел 5 проблем с памятью, 4 из которых NGINX подтвердил:

• CVE-2026-42945 (критическая, 9.2) — переполнение буфера в модуле ngx_http_rewrite_module, ведет к удаленному выполнению кода

• CVE-2026-42946 (высокая, 8.3) — чрезмерное выделение памяти (около 1 ТБ за раз), которое крашит рабочий процесс

• CVE-2026-40701 (средняя, 6.3) — обращение к уже освобожденной памяти в TLS-модуле

• CVE-2026-42934 (средняя, 6.3) — чтение за пределами выделенного буфера при обработке UTF-8

Главный баг сидит в самой основе работы NGINX со скриптами в конфигурации. Директивы rewrite и set — обычные строительные блоки любого API-шлюза: первая перезаписывает путь запроса по регулярному выражению, вторая сохраняет исходный путь в переменную, чтобы бэкенд знал, куда клиент изначально шел. Под капотом NGINX обрабатывает их в два прохода: сначала считает, сколько памяти нужно выделить под результат, потом копирует туда данные. Если в строке замены есть знак вопроса, движок ставит внутренний флаг «это аргументы запроса» — но забывает сбросить его перед следующим проходом. В итоге первый проход считает длину для обычной строки, а второй копирует туда экранированную версию, где каждый специальный символ превращается из одного байта в три. Атакующий просто добивает URI плюсами — и переполняет буфер ровно настолько, насколько ему нужно.

Дальше начинается уже эксплуатация. NGINX использует архитектуру с рабочими процессами, которые форкаются от одного главного процесса — а значит, раскладка памяти в каждом из них одинаковая. Если эксплойт уронит один процесс, главный спокойно поднимет новый с той же раскладкой, и можно пробовать снова. Через хитрое управление порядком соединений атакующий перезаписывает указатель на функцию очистки в служебной структуре пула памяти, подменяя его на вызов system() с произвольной командой — нужная подделанная структура заранее заливается в тело POST-запроса, где можно слать любые байты. Рабочий proof-of-concept выложен на GitHub, демонстрирует RCE без аутентификации. Правда, в текущем виде он требует выключенной рандомизации адресного пространства (ASLR) — защитного механизма, который раскладывает память по случайным адресам, — но авторы пишут, что в теории ее можно обойти брутфорсом.

Кроме самого NGINX Open Source, под удар попал весь экосистемный стек F5: NGINX Plus версий R32–R36, F5 WAF, NGINX App Protect, Gateway Fabric и Ingress Controller для Kubernetes. 13 мая F5 выпустил официальный security advisory с патчами. Сам факт того, что баг прожил в коде 18 лет — пройдя через сотни ревью, аудитов и контрибьюторов — и был найден ИИ-агентом за 6 часов после одного клика, добавляет аргументов в копилку дискуссии о том, как именно автономные системы будут переписывать индустрию безопасности. Заодно это намек владельцам всего, что построено на C — пора готовиться к волне старых багов, всплывающих под микроскопом машин.

P.S. Поддержать меня можно подпиской на канал «сбежавшая нейросеть«, где я рассказываю про ИИ с творческой стороны.