NGINX Rift, CVE-2026-42945: ошибке в модуле rewrite 18 лет

Что такое NGINX Rift на самом деле

CVE-2026-42945 это переполнение буфера в куче (CWE-122) в ngx_http_rewrite_module, части nginx, отвечающей за перезапись URL и логику редиректов. Согласно собственному бюллетеню F5, неавторизованный атакующий может отправить специально сформированный запрос, вызывающий несовпадение между тем, как nginx вычисляет размер буфера назначения, и тем, как он реально записывает в него данные, переполняя буфер в куче. Минимальный эффект: обрушение затронутого worker-процесса nginx, который затем перезапускается, что вызывает отказ в обслуживании. На системе с отключённой рандомизацией адресного пространства, либо там, где атакующий способен её обойти, то же переполнение можно использовать для удалённого выполнения кода.

Что запускает переполнение

Уязвимый паттерн конкретен: директива rewrite, использующая неименованную группу захвата PCRE, например $1 или $2, в строке замены, содержащей знак вопроса, за которой в том же блоке location следует ещё одна директива rewrite, if или set. Когда такая последовательность встречается, nginx вычисляет требуемый размер буфера назначения одним методом экранирования, но записывает реальный вывод другим методом, и эти два метода расходятся в том, сколько места требуется. Это расхождение и переполняет буфер. Это узкий, конкретный паттерн, а не изъян в перезаписи URL в целом, и именно поэтому он оставался незамеченным 18 лет активного реального использования модуля rewrite.

Почему 18-летняя ошибка всплыла именно сейчас

Такие ошибки обычно находят через фаззинг или целевой аудит кода широко используемого ПО, а не через обычное использование, поскольку условие срабатывания зависит от детали конфигурации, которую большинство администраторов никогда не подумали бы специально проверять. Как только F5 и проект nginx раскрыли уязвимость и выпустили исправление, PoC-код эксплойта появился быстро, а несколько источников сообщили о попытках эксплуатации сразу после этого. Это тот же паттерн, который подробно разбирает наше руководство по управлению обновлениями: в момент публикации исправления становится публичной и достаточная информация, чтобы атакующие построили рабочий эксплойт, и отсчёт того, сколько непропатченный сервер остаётся в безопасности, начинается немедленно.

Кого это касается

Затронут каждый релиз nginx Open Source с 0.6.27 по 1.30.0, а также релизы nginx Plus с R32 по R36. Учитывая, насколько давно вышла 0.6.27, это покрывает практически любое развёртывание nginx, которое не поддерживалось в актуальном состоянии, а не узкое окно недавних релизов. Согласно бюллетеню AlmaLinux, большинство крупных дистрибутивов Linux быстро перенесли исправление в свои поддерживаемые пакеты nginx, как только оно стало доступно в upstream.

Как проверить конфигурацию

nginx -v
grep -rn "rewrite" /etc/nginx/

Просмотрите найденные директивы rewrite на предмет использования неименованной группы захвата, $1, $2 и так далее, внутри строки замены со знаком вопроса, и проверьте, есть ли в том же блоке location следующая директива rewrite, if или set. Если вы нашли именно такое сочетание на затронутой версии, считайте это подтверждённой уязвимостью. Если не нашли, конкретный путь кода недостижим даже на непропатченной версии, хотя обновление всё равно правильный шаг, поскольку новые изменения конфигурации могут позже незаметно ввести этот паттерн.

Как это исправить

Обновите nginx до версии 1.30.1 или новее, если вы следите за stable-веткой, либо 1.31.0 или новее на mainline. На Debian и Ubuntu команда sudo apt update && sudo apt install nginx применяет исправление, как только ваш дистрибутив перенёс его в поддерживаемый пакет; на системах семейства RHEL эквивалент это sudo dnf upgrade nginx. Всегда проверяйте установленную версию после этого командой nginx -v, а не считайте обновление успешным по умолчанию, и подтвердите, что служба перезапустилась чисто, командой systemctl status nginx.

Если немедленное обновление невозможно, удаление или переписывание конкретного вызывающего паттерна конфигурации, неименованного захвата со знаком вопроса, за которым следует ещё одна директива rewrite, if или set в том же location, закрывает уязвимость без изменения самого бинарника nginx, хотя это временная мера, а не замена патчу.

Более общий урок

NGINX Rift хороший пример того, что фраза «мы всегда использовали эту конфигурацию и никогда не было проблем» не равна утверждению «эта конфигурация безопасна». Уязвимый путь кода в этом случае существовал с версии 0.6.27 и не имел никакого отношения к необычным или экзотическим настройкам; он зависел от конкретного, но не такого уж редкого паттерна в директивах rewrite, который многие реальные конфигурации используют для чистых URL, редиректов и обработки строк запроса. Поддержание самого nginx в актуальном состоянии, а не только конфигурации вокруг него, единственная надёжная защита от класса ошибок, которые живут в коде, не вызывающем подозрений, пока кто-то не начнёт целенаправленно его искать. Наше руководство по лучшим практикам безопасности nginx подробно разбирает настройку; эта уязвимость напоминание, что и само ПО под конфигурацией нуждается в таком же внимании.