Для критической уязвимости NGINX впервые за 18 лет выложили PoC

Для критической уязвимости CVE-2026-42945 в NGINX появились технические детали и proof-of-concept-код. Проблема получила CVSS 9.2 и затрагивает ngx_http_rewrite_module — модуль, который используется для переписывания URL, редиректов и обработки правил rewrite, if и set. NGINX уже выпустил исправления в версиях 1.30.1 stable и 1.31.0 mainline. Компания F5 устранила уязвимость в версиях NGINX Plus 37.0.0, R36 P4 и R32 P6, а также в версиях NGINX с открытым исходным кодом 1.31.0 и 1.30.1.

Уязвимость называют NGINX Rift. Она находилась в кодовой базе с 2008 года и относится к классу heap buffer overflow — переполнению буфера в куче памяти. В базовом сценарии баг позволяет удалённо и без авторизации обрушить worker-процессы NGINX, вызвав отказ в обслуживании. При небезопасных условиях эксплуатации возможен и удалённый запуск кода.

13 мая 2026 года NGINX выпустил версии 1.30.1 и 1.31.0. В релиз вошли исправления сразу нескольких проблем: HTTP/2 request injection в ngx_http_proxy_module, buffer overflow в ngx_http_rewrite_module, buffer overread в ngx_http_scgi_module и ngx_http_uwsgi_module, buffer overread в ngx_http_charset_module, address spoofing в HTTP/3 и use-after-free в OCSP-запросах к resolver.

Самая громкая из них — CVE-2026-42945. SecurityWeek пишет, что через несколько дней после патча исследователи опубликовали техническое описание и PoC-код. 

Публичный репозиторий Depthfirst описывает эксплойт как RCE PoC для серверов, где используются директивы rewrite и set. В README также указаны затронутые и исправленные версии: NGINX Open Source 0.6.27–1.30.0, исправлено в 1.30.1 и 1.31.0; NGINX Plus R32–R36, исправлено в R32 P6, R35 P2 и R36 P4.

Проблема — в двухпроходной логике script engine NGINX. Сначала движок считает, сколько памяти нужно выделить под результат переписывания URL. Затем копирует данные в выделенный буфер. Ошибка возникает, когда состояние движка на этапе подсчёта и на этапе копирования расходится.

Depthfirst описывает ключевое условие: replacement-строка в rewrite содержит знак вопроса ?, а в правилах используются захваты регулярных выражений. На этапе подсчёта размер получается меньше нужного, а на этапе копирования часть URI экранируется и расширяется. В итоге данные, контролируемые атакующим, выходят за границу выделенного heap-буфера.

Orca Security объясняет опасный паттерн проще: особенно рискованны конфигурации с rewrite, if или set, где используются безымянные regex-captures вроде $1 или $2. Если такой сервер выходит в интернет, атакующему может хватить специально подготовленного HTTP-запроса.

Под ударом:

• NGINX Open Source 0.6.27–1.30.0;

• NGINX Plus R32–R36;

• зависимые продукты и образы, которые включают уязвимый NGINX;

• часть Kubernetes ingress-развёртываний, если они используют уязвимые версии и опасные rewrite-конфигурации.

Orca указывает связанные продукты: NGINX Ingress Controller, NGINX Gateway Fabric, NGINX App Protect WAF, F5 WAF for NGINX и решения защиты от DoS, если внутри используется уязвимая версия. Broadcom подтвердила выпуск обновлённых Bitnami-контейнеров и Helm-чартов для затронутых клиентов.

Не каждый сервер с NGINX автоматически уязвим в одинаковой степени. Нужна конкретная конфигурация с rewrite-логикой. Но проверять стоит все инстансы: вручную установленный NGINX, контейнеры, ingress-controller в Kubernetes, старые reverse-proxy, тестовые стенды, appliance-образы и embedded-поставки внутри сторонних продуктов.

Патч вышел до публикации эксплуатационных деталей. После появления PoC у атакующих появляется готовая логика проверки: найти NGINX, определить версию и конфигурационные признаки, отправить crafted request, посмотреть на падение worker-процесса или ответ сервера.

Главное действие — обновление. Для NGINX Open Source нужны 1.30.1 или 1.31.0. Для NGINX Plus — исправленные сборки R32 P6, R35 P2 или R36 P4. Для контейнеров и Helm-чартов нужно тянуть свежие образы от поставщика, а не просто пересобрать приложение поверх старого base image.

Если обновиться сразу нельзя, временная mitigation — пересмотреть конфигурацию и заменить безымянные regex-captures на именованные captures в опасных rewrite-директивах. Orca и Broadcom описывают именно этот вариант как временное снижение риска. Но это не полноценная замена патча: конфигурации часто размазаны по include-файлам, Helm values, шаблонам ingress и старым snippets.

Проверять стоит не только /etc/nginx/nginx.conf. В реальной инфраструктуре правила могут лежать в conf.d, sites-enabled, Kubernetes annotations, ConfigMap, Helm values, Terraform-шаблонах, Ansible-ролях и образах, собранных год назад. Отдельное внимание — кастомным rewrite-правилам для legacy-приложений, SEO-редиректов, CDN-origin, API gateway и multi-tenant ingress.

Для DoS-сценария признаки будут довольно грубыми: падения worker-процессов, быстрый PID cycling, ошибки heap corruption, SIGABRT, всплески 502/503/504, нестабильные health checks, короткие серии странных GET-запросов к URL с большим числом экранируемых символов.

Для RCE-сценария публичных универсальных IOC нет. Поэтому смотреть нужно шире: неожиданные дочерние процессы у NGINX worker, сетевые исходящие соединения от nginx-процесса, новые файлы во временных директориях, изменения конфигурации, странные POST/GET-паттерны перед падениями worker и любые следы выполнения shell-команд.