Критическая уязвимость NGINX Rift позволяла удалённо выполнять код - она скрывалась 18 лет

NGINX

13 мая 2026 года исследователи безопасности раскрыли критическую уязвимость в веб-сервере NGINX, которая оставалась незамеченной в коде почти два десятилетия. Она получила название NGINX Rift и идентификатор CVE-2026-42945, а её рейтинг по шкале CVSS (система оценки критичности уязвимостей) составил 9,2 балла из десяти - то есть "критический" уровень опасности. Поскольку NGINX обслуживает около трети всех сайтов в мире и является ключевым элементом бесчисленных серверных инфраструктур, обнаружение уязвимости, позволяющей неавторизованному злоумышленнику выполнить произвольный код удалённо, несёт серьёзные последствия для организаций по всему миру.

Уязвимость CVE-2026-42945 (NGINX Rift)

Суть проблемы кроется в модуле ngx_http_rewrite_module, который отвечает за перезапись URL-адресов. В реальных конфигурациях директивы rewrite и set используются совместно, поэтому уязвимость затронула огромное количество корпоративных сред. При определённых условиях NGINX некорректно обрабатывает память во время выполнения особых правил перезаписи. Злоумышленник может отправить специально сформированный HTTP-запрос, который вызовет переполнение буфера в куче - heap buffer overflow. Это даёт ему возможность перезаписать соседние области памяти и в конечном счёте получить полный контроль над процессом.

Помимо этой критической проблемы, исследователи обнаружили ещё три уязвимости, которые были исправлены в том же обновлении. Уязвимость CVE-2026-42946 (8,3 балла) приводила к отказу в обслуживании в модулях SCGI и uWSGI через чрезмерное выделение памяти. CVE-2026-40701 (6,3 балла) - use-after-free (обращение к уже освобождённой памяти) в SSL-модуле при обработке некоторых сценариев TLS и OCSP. И CVE-2026-42934 (6,3 балла) - чтение за границами буфера в модуле charset при обработке неполных UTF-8-последовательностей.

Под удар попали не только открытая версия NGINX, но и коммерческие продукты на его основе: NGINX Plus, NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF, NGINX App Protect DoS, NGINX Gateway Fabric и контроллер входящего трафика NGINX Ingress Controller. Компания F5 уже выпустила обновления для затронутых версий, и администраторам настоятельно рекомендуется установить их как можно скорее.

Временной мерой защиты может служить проверка конфигураций, в которых правила rewrite содержат знак вопроса вместе с директивами set, ссылающимися на захваченные значения. Также стоит усилить мониторинг подозрительных HTTP-запросов с сильно закодированными полезными нагрузками или необычными шаблонами URL - это может указывать на попытки эксплуатации.

Теперь разберёмся, как работает атака. Эксплойт использует несоответствие между двумя фазами обработки одного и того же набора инструкций. Когда в правиле rewrite встречается знак вопроса, внутренний флаг e→is_args устанавливается в единицу и остаётся в таком состоянии для последующих операций. При вычислении длины буфера для захваченного значения используется новый внутренний движок, где этот флаг равен нулю, поэтому длина считается без учёта экранирования. Но при фактическом копировании данных движок видит флаг единицу и применяет экранирование каждого специального символа, расширяя его с одного байта до трёх. Злоумышленник может заполнить запрос большим количеством плюсов или амперсандов, и каждый из них при копировании превратится в три байта, переполняя отведённый буфер.

Далее атакующий выбирает цель для перезаписи - поле очистки соседней структуры пула памяти. Это поле содержит указатель на связный список обработчиков очистки, каждый из которых хранит указатель на функцию и аргумент для неё. Когда пул уничтожается, NGINX вызывает эти функции. Подменив указатель на список, злоумышленник может заставить сервер выполнить произвольную команду, например, вызов system из стандартной библиотеки libc.

Но есть сложность: переполнение записывает данные последовательно, поэтому для достижения поля cleanup приходится затирать все предыдущие метаданные пула. Любая операция, которая обратится к этим испорченным данным после переполнения, вызовет аварийное завершение процесса. Чтобы обойти это, используется техника "кучного фэн-шуя": сначала открывается одно соединение, которое частично отправляет заголовки, вынуждая NGINX выделить пул для запроса. Затем открывается второе "жертвенное" соединение, чей пул оказывается соседним с первым. После этого первый запрос завершается, вызывая переполнение, и сразу же закрывается второе соединение - это заставляет сервер вызвать функцию уничтожения пула, пока никто не успел прочитать повреждённые метаданные.

Для внедрения фиктивной структуры очистки с командой злоумышленник использует тело HTTP-запроса POST, которое обрабатывается как поток сырых байтов и может содержать любые значения, включая нулевые байты. Через распыление в куче (heap spray) он размещает поддельный объект в предсказуемом месте памяти, указывающий на system. За счёт форк-модели NGINX все рабочие процессы наследуют одинаковое расположение памяти от родительского процесса, поэтому адреса становятся детерминированными. Остаётся лишь подобрать адрес, составленный из символов, безопасных для URI, и перезаписать младшие байты указателя cleanup.

При закрытии сокета "жертвенного" соединения ngx_destroy_pool обходит подменённый список и вызывает system с командой, заложенной атакующим. Так достигается неавторизованное удалённое выполнение кода внутри рабочего процесса NGINX.

Для специалистов по информационной безопасности это событие - серьёзный сигнал. Уязвимость скрывалась в коде 18 лет и была найдена лишь сейчас. Организациям необходимо немедленно провести инвентаризацию всех систем, где используется NGINX, и применить патчи. Тем, кто не может обновиться немедленно, стоит временно отключить или переписать конфигурации, использующие директивы rewrite и set вместе со знаком вопроса. Мониторинг аномальных HTTP-запросов также поможет выявить возможные атаки. Учитывая масштаб распространения NGINX, промедление может стоить очень дорого.

Ссылки

Комментарии: 0