В NGINX Plus и NGINX Open Source выявлена критическая уязвимость CVE-2026-42945 (NGINX Rift, CVSS v4 9.2) в модуле ngx_http_rewrite_module, существовавшая незамеченной 18 лет и позволяющая удалённое выполнение кода или отказ в обслуживании по неаутентифицированному HTTP‑запросу; под удар попадают веб‑серверы, reverse‑proxy, ingress‑контроллеры и WAF на базе NGINX, а администраторам необходимо немедленно обновить версии или изменить конфигурацию rewrite‑правил, исключив небезопасные регулярные выражения.

Технические детали уязвимостей

Исходный дефект NGINX Rift / CVE-2026-42945 обнаружен исследователями проекта depthfirst и подробно описан в их разборе NGINX Rift. Согласно уведомлению F5 для клиентов NGINX (официальный advisory F5), проблема представляет собой переполнение буфера в куче в модуле ngx_http_rewrite_module, возникающее при специфической комбинации директив и регулярных выражений.

Условие эксплуатации CVE-2026-42945 выглядит так:

• используется модуль ngx_http_rewrite_module с директивой rewrite,
• за ней следует директива rewrite, if или set,
• в правилах используют безымянные PCRE‑захваты ($1, $2 и т.д.),
• в строке замены присутствует символ ?.

Удалённый, неаутентифицированный атакующий, способный отправлять HTTP‑запросы на уязвимый сервер, формирует специально подготовленный URI, который приводит к переполнению кучи в процессе worker NGINX. При включённом ASLR это, как минимум, надёжный способ вызывать краш и перезапуск worker (отказ в обслуживании). При отключённом ASLR, по оценке depthfirst и F5, становится достижимо удалённое выполнение кода в контексте процесса NGINX. См. также запись в NVD: CVE-2026-42945.

Особенность уязвимости в том, что:

• эксплуатация не требует аутентификации или предварительного доступа;
• одного запроса достаточно для переполнения кучи;
• записываемые за пределы выделенного блока байты полностью контролируются атакующим через URI, что делает коррупцию памяти целенаправленной, а не случайной;
• повторяющиеся запросы могут ввести worker‑процессы в цикл падений, снижая доступность всех сайтов на экземпляре.

По данным F5, уязвимость затрагивает:

• NGINX Plus R32–R36 (исправлено в R32 P6 и R36 P4);
• NGINX Open Source 1.0.0–1.30.0 (исправлено в 1.30.1 и 1.31.0);
• NGINX Open Source 0.6.27–0.9.7 (исправлений не планируется);
• ряд продуктов на базе NGINX: NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF/DoS, NGINX Gateway Fabric, NGINX Ingress Controller — в конкретных диапазонах версий, перечисленных в advisory F5.

Дополнительные уязвимости в NGINX

Одновременно исправлены ещё три уязвимости средней и высокой степени опасности:

• CVE-2026-42946 (CVSS v4 8.3) — в модулях ngx_http_scgi_module и ngx_http_uwsgi_module. Неаутентифицированный атакующий с возможностью перехвата и модификации ответов upstream‑сервера (adversary-in-the-middle) способен сформировать такие ответы, что NGINX некорректно управляет памятью worker‑процесса, что ведёт к чтению данных из его памяти или перезапуску процесса при использовании директив scgi_pass или uwsgi_pass. См. advisory по CVE-2026-42946 и запись CVE-2026-42946.
• CVE-2026-40701 (CVSS v4 6.3) — use-after-free в ngx_http_ssl_module. Условие: ssl_verify_client установлена в on или optional, а ssl_ocsp — в on. Это позволяет удалённому неаутентифицированному злоумышленнику в ограниченной степени модифицировать данные или вызвать перезапуск worker‑процесса. См. advisory по CVE-2026-40701 и CVE-2026-40701.
• CVE-2026-42934 (CVSS v4 6.3) — чтение за пределами буфера в ngx_http_charset_module. Риск раскрытия содержимого памяти или перезапуска worker при одновременной конфигурации директив charset, source_charset, charset_map и proxy_pass с отключённым буферизованием (off). См. advisory по CVE-2026-42934 и CVE-2026-42934.

В исходных уведомлениях не говорится о зафиксированной эксплуатации этих уязвимостей в реальных атаках, но технический профиль CVE-2026-42945 делает её привлекательной целью для автоматизации и массового сканирования.

Контекст и особенности угрозы

NGINX традиционно используется как высоконагруженный веб‑сервер и reverse‑proxy, а также как основа ingress‑контроллеров в Kubernetes и коммерческих решений F5. Ошибка в rewrite‑механизме, существовавшая с ранних версий (0.6.x), показательно демонстрирует риски «пограничной» логики: нестандартные комбинации директив, интеграция с PCRE и сложные URI‑шаблоны исторически тестируются хуже, но активно применяются в реальных конфигурациях.

Критически важно, что уязвимый участок кода достигается до каких‑либо проверок аутентификации приложения или бизнес‑логики. Фактически NGINX здесь выступает как сама поверхность атаки. Это повышает ценность уязвимости для атакующих: достаточно только сетевой доступности HTTP‑порта, даже если далее за NGINX скрыт хорошо защищённый backend.

Дополнительные уязвимости (SCGI/UWSGI, SSL, charset) иллюстрируют другой класс проблем: когда NGINX доверяет содержимому от upstream‑сервера или инфраструктуры проверки сертификатов (OCSP), ошибки обработки этих данных позволяют выйти за ожидаемые границы памяти. В сценариях, где злоумышленник контролирует или может подменять upstream‑ответы, такие дефекты превращаются в мощный инструмент для чтения фрагментов памяти или отключения сервисов.

Оценка воздействия

Под наибольшим риском находятся:

• организации, использующие NGINX как публичный веб‑сервер или reverse‑proxy с активным ngx_http_rewrite_module, особенно с большим числом сложных правил;
• облака и хостинг‑провайдеры, где один экземпляр NGINX обслуживает множество арендаторов: успешная эксплуатация CVE-2026-42945 может повлиять на всех клиентов на данном узле;
• Kubernetes‑кластеры с NGINX Ingress Controller, а также инсталляции NGINX App Protect WAF/DoS и NGINX Gateway Fabric в уязвимых версиях;
• системы, где ASLR отключён или ослаблен (например, специализированные аплаиансы или сильно оптимизированные для производительности окружения).

При отсутствии мер реагирования возможны следующие последствия:

• полный захват узла через RCE в процессе NGINX (CVE-2026-42945) с последующим движением внутри сети;
• компрометация конфиденциальных данных за счёт чтения фрагментов памяти worker‑процесса (CVE-2026-42946, CVE-2026-42934), где могут находиться токены, cookie, части запросов и ответов;
• широкомасштабный отказ в обслуживании — циклические падения worker‑процессов, недоступность сайтов и API, рост латентности и ошибок 502/504;
• косвенные потери: репутационные риски, нарушение SLA, возможные штрафы за утечку персональных данных.

Практические рекомендации

1. Приоритизация и сроки

• Рассматривать CVE-2026-42945 как критическую: обновление или применение обходного решения — в приоритете «немедленно/в течение ближайших часов» на публично доступных узлах.
• Остальные уязвимости (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) — приоритет «высокий», планировать обновление в ближайшее окно обслуживания.

2. Обновление до исправленных версий

• Для NGINX Plus обновиться как минимум до R32 P6 или R36 P4 либо более новых выпусков, содержащих исправления (см. advisory F5).
• Для NGINX Open Source — перейти на 1.30.1 или 1.31.0 и выше.
• Для продуктов на базе NGINX (Ingress Controller, App Protect WAF/DoS, Gateway Fabric, Instance Manager, F5 WAF for NGINX) — сопоставить текущие версии с диапазонами, указанными в соответствующих advisory F5, и обновиться до рекомендованных релизов.
• Для очень старых веток 0.6.27–0.9.7, где исправления не планируются, единственный путь — миграция на поддерживаемые версии.

3. Обходное решение для CVE-2026-42945

Если немедленное обновление недоступно, рекомендуется изменить конфигурацию rewrite‑правил, как описано F5 и depthfirst:

• Найти все директивы rewrite, за которыми следует rewrite, if или set, где:
  • используются безымянные захваты вида $1, $2 и т.п.;
  • в строке замены присутствует символ ?.
• Переопределить регулярные выражения с использованием именованных захватов PCRE, например:
  • было: rewrite ^/user/(\d+)\?(.*)$ /profile.php?id=$1?$2;
  • стало: rewrite ^/user/(?<uid>\d+)\?(?<rest>.*)$ /profile.php?id=$uid?$rest;
• Проверить после правок, что функциональность перенаправлений сохраняется, и перезапустить NGINX.

Суть обхода: перевод безымянных захватов в именованные меняет путь обработки данных в коде NGINX и исключает уязвимый сценарий.

4. Снижение риска по дополнительным уязвимостям

До обновления можно временно сократить поверхность атаки:

• Для CVE-2026-42946: по возможности ограничить или временно отключить scgi_pass и uwsgi_pass на внешних границах, особенно там, где upstream может быть под контролем третьих лиц.
• Для CVE-2026-40701: при невысокой критичности проверки клиента и OCSP рассмотреть временное отключение ssl_ocsp on или ослабление ssl_verify_client, оценив при этом влияние на требования по аутентификации клиента.
• Для CVE-2026-42934: минимизировать использование charset_map в сочетании с proxy_pass и отключённым буферизованием, если это возможно без ущерба для бизнеса.

5. Проверка подверженности и мониторинг

• Проверить версию NGINX командой nginx -v и сопоставить с диапазонами уязвимых версий.
• Проанализировать конфигурацию:
  • поиск по nginx.conf и включённым файлам по ключам rewrite, $1, $2, ?;
  • выделить правила, удовлетворяющие описанному выше паттерну.
• Включить или усилить логирование ошибок NGINX и системное логирование:
  • обратить внимание на повторяющиеся падения worker‑процессов, сигналы segmentation fault, цикличные перезапуски;
  • сопоставлять эти события с подозрительными HTTP‑запросами, содержащими нестандартные URI с ? и сложными паттернами.
• Убедиться, что на серверах включён ASLR на уровне операционной системы как дополнительный рубеж защиты от RCE, даже после установки патчей.

Ключевое действие для владельцев инфраструктуры на базе NGINX — в кратчайшие сроки обновить NGINX Plus, NGINX Open Source и связанные продукты до версий с исправлениями CVE-2026-42945 и сопутствующих уязвимостей, а при задержках с обновлением немедленно провести ревизию rewrite‑правил с заменой безымянных захватов на именованные во всех конфигурациях, доступных из интернета.