Уязвимость NGINX Rift (CVE-2026-42945): 18-летняя дыра с RCE и чем она грозит серверам на 1С-Битрикс

В nginx обнаружили критическую уязвимость CVE-2026-42945 (CVSS 9.2): ошибка в модуле ngx_http_rewrite_module позволяет неаутентифицированному злоумышленнику одним HTTP-запросом обрушить рабочий процесс веб-сервера, а на системах с отключённым ASLR — добиться выполнения произвольного кода. Баг прожил в коде 18 лет и затрагивает практически все выпуски nginx вплоть до исправленных 1.30.1 и 1.31.0, включая сборки в составе 1С-Битрикс, панелей управления и российского форка Angie. Покажем, как быстро проверить, уязвим ли ваш сервер, и закрыть дыру без простоя.

CVE-2026-42945 (публичное имя NGINX Rift) — это уязвимость класса heap-based buffer overflow (CWE-122) в модуле ngx_http_rewrite_module, который входит в стандартную сборку и NGINX Plus, и NGINX Open Source. То есть это не редкий дополнительный модуль, а штатный механизм перезаписи URL, работающий почти на каждом веб-сервере и обратном прокси.

Брешь срабатывает в узком, но повсеместном сценарии конфигурации: когда директива rewrite идёт следом за другой директивой rewrite, if или set, использует безымянный захват PCRE (те самые $1, $2), а строка замены содержит знак вопроса (?). Именно сочетание «безымянный захват плюс вопросительный знак в подстановке» и переполняет буфер в куче.

Последствие переполнения: порча кучи в рабочем процессе (worker process) nginx, что приводит к его перезапуску, то есть к отказу в обслуживании. Это базовый, гарантированный исход. Сверх того, на системах с отключённым ASLR или там, где атакующий способен его обойти, открывается путь к выполнению произвольного кода.

F5 Networks оценила уязвимость в 8,1 (HIGH) по шкале CVSS 3.1 и в 9,2 (CRITICAL) по CVSS 4.0 (подробности в карточке NVD и официальном реестре CVE). Разрыв между оценками объясняется вектором: атака сетевая и не требует аутентификации (AV:N), но сложность высокая (AC:H), и в описании прямо сказано про «условия вне контроля атакующего». Запись обновлялась 21 мая 2026 года, так что данные свежие и ещё уточняются.

По нашему опыту самое коварное здесь — ложное чувство безопасности: администраторы считают, что rewrite-правила «безобидные», тогда как именно они и есть поверхность атаки. Если у вас в конфигах живут SEF-редиректы со ссылками на $1 и подстановкой query-string, считайте, что сервер потенциально затронут, пока не доказано обратное.

Почти два десятилетия ngx_http_rewrite_module проходил через ручные аудиты, статические анализаторы и фаззинг, и никто не заметил переполнения. Публичное раскрытие под названием Nginx-Rift опубликовала команда DepthFirst Disclosures, материалы доступны в их разборе Nginx-Rift и в репозитории на GitHub, а официальная карточка вендора ведёт на my.f5.com (статья K000160932). По публичным сообщениям, баг был выявлен автономным ИИ-агентом, а не человеком вручную.

Почему его так долго не находили — вопрос не про невнимательность, а про природу дефекта. Уязвимость недостижима «в лоб»: она срабатывает только при конкретном сочетании директив в конфигурации: rewrite за rewrite, if или set с безымянным захватом $1/$2 и ? в строке замены. Классический фаззинг гоняет входные данные при фиксированном конфиге и такую ветку попросту не достаёт.

Сильная сторона автономного агента в том, что он способен перебирать не только запросы, но и пространство самих конфигураций: комбинации директив, которые человек считает «нормальными» и потому не проверяет. Это смещает фокус с «какой запрос ломает сервер» на «какая связка настроек делает сервер ломаемым».

Мы не раз проводили аудит nginx-конфигов на проектах и честно скажем: подобную связку директив глазами почти не отлавливают, потому что каждая строка по отдельности абсолютно легитимна. Опасность рождается на стыке, а ревью обычно смотрит на директивы по одной.

Практический вывод для команд эксплуатации простой. Раскрытие через ИИ-агента означает, что аналогичные «спящие» дефекты в других модулях, скорее всего, начнут всплывать чаще и быстрее. Следите за карточкой уязвимости и страницей вендора, а не полагайтесь на разовую проверку.

Главное в одном предложении: неаутентифицированный атакующий отправляет специально сформированные HTTP-запросы, которые через уязвимый rewrite-сценарий переполняют кучу рабочего процесса nginx и роняют его с перезапуском. Это и есть базовый, надёжно воспроизводимый эффект — отказ в обслуживании без каких-либо учётных данных. По сообщениям профильных изданий (в частности, xakep.ru), уже зафиксированы первые случаи попыток эксплуатации, так что окно «спокойно подождём» закрыто.

Выполнение кода — отдельная, более высокая планка. RCE возможен на системах, где ASLR отключён либо атакующий способен его обойти. На современных дистрибутивах Linux ASLR включён по умолчанию, поэтому массового удалённого исполнения кода ожидать не стоит — но это не повод расслабляться. Контейнеры с урезанными настройками ядра, старые или кастомные сборки, встроенные системы и виртуалки, где ASLR выключали «ради стабильности», превращают теоретический RCE во вполне реальный.

Высокая сложность атаки (AC:H в векторе CVSS) напрямую отражена в формулировке вендора про «условия вне контроля атакующего»: нужен и уязвимый конфиг на стороне сервера, и подходящее состояние памяти. Поэтому не путайте «сложно» с «безопасно» — для DoS этот барьер берётся куда легче, чем для RCE.

Не отключайте ASLR ради мнимой производительности или совместимости со старым софтом — мы сталкивались с тем, как на сервере с выключенной рандомизацией адресного пространства локальная, казалось бы, проблема превращалась в полноценный плацдарм для удалённого исполнения. На наших проектах статус ASLR теперь входит в обязательный чек-лист приёмки сервера, и переполнение в куче — ровно тот класс багов, ради которого этот пункт и существует.

Под прицелом в первую очередь публичные периметры: фронтенды, обратные прокси и балансировщики, принимающие трафик из интернета. Если nginx стоит на входе и обрабатывает пользовательские URL через rewrite, он находится на линии огня вне зависимости от того, что крутится за ним.

В зоне риска любая установка, где nginx (NGINX Plus или Open Source) обслуживает rewrite-правила с безымянными захватами $1/$2 и знаком ? в строке замены. А это, к сожалению, описывает почти весь российский веб-хостинг массового сегмента.

1С-Битрикс и поставляемый с ним BitrixVM — первый кандидат. Движок активно использует ЧПУ (человекопонятные URL) и SEF-маршрутизацию, а это десятки rewrite-правил с подстановкой в index.php?.... Коробочный Bitrix24 наследует ту же логику (см. порты и сервисы коробочного Битрикс24). По нашему опыту в типовых конфигах Bitrix паттерн «rewrite с $1 плюс query-string через ?» встречается практически всегда, не как экзотика, а как штатная схема ЧПУ.

Панели управления ISPmanager и Plesk генерируют nginx-конфиги автоматически, и админ редко заглядывает в итоговые файлы. Docker-образы с nginx тащат за собой ту же сборку модуля; обновление базового образа без пересборки оставляет дыру внутри контейнера. Отдельная категория — самописные обратные прокси и API-шлюзы, где rewrite используют для маршрутизации между бэкендами.

Ключевой нюанс: уязвимость зависит от конфигурации, а не только от версии бинарника. Поэтому «у меня свежий пакет» — недостаточный аргумент, пока вы не проверили сами правила перезаписи. На наших проектах мы первым делом инвентаризируем, где именно nginx смотрит наружу и какие из этих точек обрабатывают пользовательские URL, и приоритет закрытия выстраиваем от публичного периметра внутрь. Похожие инциденты мы разбираем на практике: например, как мы спасли сайт клиента на Битрикс после атаки.

Начнём с честного ответа, потому что вокруг Angie много домыслов. В карточке CVE-2026-42945 официально перечислены только NGINX Plus и NGINX Open Source, и Angie в ней по имени не упомянут. Делать из этого вывод «Angie в безопасности» нельзя: Angie — это форк nginx, развиваемый бывшими разработчиками оригинала, и базовый ngx_http_rewrite_module он наследует из той же кодовой базы.

Практический принцип, который мы применяем: раз уязвимость зависит от конфигурации, а не только от названия дистрибутива, аудит rewrite-правил обязателен для любой сборки: оригинальный nginx, Angie или другой форк. Проверка собственных конфигов не зависит от того, попал ли ваш продукт в официальный список CVE.

И это не теория: разработчики Angie подтвердили проблему и выпустили исправления. CVE-2026-42945 закрыт в версии Angie 1.11.5, а связанная с ним CVE-2026-9256 (вторая критическая уязвимость в том же rewrite-модуле, CVSS 9.2) закрыта в Angie 1.11.6, куда фикс портировали из nginx 1.31.1. Практический вывод: обновляйтесь минимум до Angie 1.11.6, чтобы закрыть обе уязвимости разом, и следите за бюллетенями обоих вендоров: F5 (статья K000160932) и Angie.

Для организаций, которые мигрировали с зарубежного ПО на отечественные форки, риск двойной. Во-первых, при переезде часто переносят и старые rewrite-конфиги «как есть», вместе с уязвимым паттерном. Во-вторых, у форков собственный цикл выпуска исправлений, и он может отставать от F5.

Поэтому минимальная гигиена здесь — вести инвентаризацию того, где и какая сборка nginx/Angie работает, подписаться на бюллетени безопасности обоих вендоров и не считать импортозамещённый продукт автоматически защищённым только потому, что его нет в исходной карточке CVE.

Прямой ответ: за несколько минут нужно сделать пять вещей — снять версию и параметры сборки, просканировать конфиги на уязвимый паттерн (для системной проверки конфигурации удобны линтеры nginx), проверить статус ASLR, при необходимости включить его и проверить логи на аварийные перезапуски. Начнём с версии и флагов сборки, включая поддержку PCRE и наличие rewrite-модуля.

Главное — найти опасную связку в конфигах: строки с безымянным захватом $1/$2 и знаком ? в строке замены, как в примере ниже, рядом с rewrite, if или set. Если grep находит такое на хосте, смотрящем в интернет, считайте это приоритетом номер один. Ложные срабатывания: переменные $host, $request_uri, $uri и именованные захваты вида (?P<name>...) в этот паттерн не попадают — grep нацелен именно на безымянные числовые ссылки $1, $2.

Отдельно проверьте ASLR командой cat /proc/sys/kernel/randomize_va_space: значение 2 означает полную рандомизацию адресного пространства, 1 частичную, а 0 говорит, что защита выключена и риск RCE максимальный. ASLR нужно держать включённым: именно он удерживает уязвимость на уровне отказа в обслуживании и не даёт ей дорасти до удалённого исполнения кода. На дефолтных дистрибутивах рандомизация активна (значение 2), но в контейнерах, старых и кастомных сборках её иногда отключают ради совместимости. Если команда вернула 0, включите ASLR командами из шага 4 ниже и сделайте значение постоянным, чтобы оно пережило перезагрузку.

Последний шаг — следы в логах: переполнение проявляется падением рабочего процесса с последующим рестартом. Сигнал 11 (SIGSEGV) или 6 (SIGABRT) рядом с записями о перезапуске воркера — тревожный признак, который стоит сопоставить с всплеском внешних запросов по времени. Команды из шага 5 ниже покажут характерные строки в error.log и системном журнале.

На наших проектах мы добавили эти проверки в стандартный чек-лист реагирования и прогоняем их по всему парку, а не только на «подозрительных» серверах: уязвимость зависит от конфига, и сюрпризы вылезают там, где их не ждёшь. Если нашли совпадения, переходите к закрытию, не дожидаясь повторного падения.

Главная мера — обновление до исправленной версии. F5 закрыла CVE-2026-42945 в nginx 1.30.1 (стабильная ветка) и 1.31.0 (mainline), а для NGINX Plus в редакциях R36 P4 и R32 P6; связанная CVE-2026-9256 закрыта в nginx 1.31.1. Точную версию под ваш дистрибутив сверяйте по официальной карточке вендора (my.f5.com, статья K000160932), потому что дистрибутивы часто бэкпортируют фикс в свои сборки без смены номера. Отдельно учтите, что версии, достигшие конца технической поддержки (EoTS), вендором вообще не оценивались, и если вы на такой ветке, обновление редакции для вас не опция, а необходимость.

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

Пока обновление не приехало в ваш дистрибутив, есть логичная временная мера: убрать из rewrite-правил уязвимую связку — заменить безымянные захваты $1/$2 на именованные:

Было (уязвимо):
rewrite ^/catalog/(.*)$ /index.php?path=$1 last;
Стало (безопасно):
rewrite ^/catalog/(?P<path>.*)$ /index.php?path=$path last;

Знак ? в замене остаётся, но безымянный $1 исчезает и уязвимость не срабатывает. Переменные $host, $request_uri, $uri не являются безымянными захватами, трогать их не нужно.

WAF имеет смысл подключить как дополнительный рубеж, но не как замену исправления. Поскольку триггер находится в вашей конфигурации, а не в одной легко сигнатурируемой строке запроса, надёжно отфильтровать все варианты эксплуатации фильтром на входе не выйдет. Не полагайтесь на WAF как на единственную защиту — мы сталкивались с ситуацией, когда клиент с дорогим экраном откладывал обновление неделями, а реальную брешь в конфиге это никак не закрывало.

Наш рекомендуемый порядок такой: сначала прицельно правим опасные rewrite-правила (минуты работы, эффект сразу), затем накатываем обновление редакции по данным вендора и перезагружаемся без простоя, и только поверх этого держим WAF как страховку.

Разбираем вопросы, которые чаще всего возникают у администраторов при закрытии CVE-2026-42945.

Константин Тютюнник — ведущий инженер DevOps в IT For Prof. Специализируется на высоконагруженных проектах и безопасности веб-серверов. Имеет более 10 лет опыта администрирования NGINX в инфраструктурах e-commerce и финтеха.