В nginx нашли критическую уязвимость CVE-2026-42945 (CVSS 9.2): один HTTP-запрос без авторизации роняет рабочий процесс веб-сервера, а на системах с отключённым ASLR открывает дорогу к выполнению чужого кода. Баг прожил в коде 18 лет и сидит почти во всех сборках вплоть до исправленных 1.30.1 и 1.31.0 — включая 1С-Битрикс, панели управления и российский форк Angie.
Первые попытки эксплуатации уже зафиксированы, так что окно «спокойно подождём» закрылось. Разберём, как за пять минут проверить свой сервер и закрыть дыру без простоя.
Как одна строка в конфиге роняет nginx
Уязвимость живёт в модуле ngx_http_rewrite_module — штатном механизме перезаписи URL, который работает почти на каждом веб-сервере и обратном прокси. Это не редкий сторонний модуль, а часть базовой сборки и NGINX Open Source, и NGINX Plus.
Класс бага — переполнение кучи (heap-overflow). Срабатывает он в узком, но повсеместном сценарии: когда директива rewrite идёт следом за другой rewrite, if или set, использует безымянный захват вида $1 или $2, а строка замены содержит знак вопроса. Именно связка «безымянный захват плюс вопросительный знак в подстановке» переполняет буфер.
Базовый исход — порча памяти и перезапуск рабочего процесса, то есть отказ в обслуживании. Этого результата атакующий добивается гарантированно и без всяких учётных данных. Выполнение чужого кода — отдельная, более высокая планка, и о ней ниже.
Самое коварное здесь — ложное чувство безопасности: каждая строка rewrite по отдельности абсолютно легитимна, а опасность рождается на стыке директив. Ревью обычно смотрит на правила по одному и связку не ловит.
Любопытна история находки: 18 лет модуль проходил ручные аудиты, статические анализаторы и фаззинг — и никто не замечал дефект. Уязвимость нашёл автономный ИИ-агент, потому что перебирал не только запросы, но и сами комбинации директив, которые человек считает «нормальными».
Какие сборки и панели под ударом
В зоне риска любая установка, где nginx обслуживает rewrite-правила с безымянными захватами $1 / $2 и знаком вопроса в строке замены. А это описывает почти весь российский веб-хостинг массового сегмента.
1С-Битрикс и поставляемый с ним BitrixVM — первый кандидат. Движок активно использует человекопонятные URL и SEF-маршрутизацию, а это десятки правил с подстановкой в index.php. В типовых конфигах Битрикса паттерн «rewrite с $1 плюс query-string через знак вопроса» встречается не как экзотика, а как штатная схема ЧПУ. Коробочный Bitrix24 наследует ту же логику.
- 1С-Битрикс / BitrixVM — системный nginx, SEF-правила с $1 и ?path=
- ISPmanager и Plesk — конфиги генерируются автоматически, и админ редко заглядывает в итоговые файлы
- Docker-образы — тащат за собой ту же сборку модуля; обновление базового образа без пересборки оставляет дыру внутри контейнера
- Самописные обратные прокси и API-шлюзы — где rewrite применяют для маршрутизации между бэкендами
Отдельная история — Angie. В карточке CVE он по имени не упомянут, но это форк nginx на той же кодовой базе, и уязвимый модуль он наследует. Разработчики проблему подтвердили: CVE-2026-42945 закрыт в Angie 1.11.5, а связанная CVE-2026-9256 — в 1.11.6. Обновляйтесь минимум до 1.11.6, чтобы закрыть обе разом.
Ключевой нюанс: уязвимость зависит от конфигурации, а не только от версии бинарника. «У меня свежий пакет» — недостаточный аргумент, пока вы не проверили сами правила перезаписи.
Где риск выполнения кода максимален
На современных дистрибутивах Linux рандомизация адресного пространства (ASLR) включена по умолчанию, поэтому массового удалённого исполнения кода ждать не стоит — переполнение остаётся на уровне отказа в обслуживании.
Опасны места, где ASLR выключен. Контейнеры с урезанными настройками ядра, старые и кастомные сборки, встроенные системы и виртуалки, где рандомизацию отключали «ради стабильности», превращают теоретический RCE во вполне реальный. На сервере с выключенной защитой локальная проблема легко становится плацдармом для удалённого выполнения кода.
Под прицелом в первую очередь публичные периметры: фронтенды, обратные прокси и балансировщики, принимающие трафик из интернета. Если nginx стоит на входе и обрабатывает пользовательские URL через rewrite, он на линии огня вне зависимости от того, что крутится за ним.
Как за пять минут проверить сервер
Сначала снимите версию и флаги сборки. Команды nginx -v и nginx -V покажут номер выпуска и наличие rewrite-модуля с поддержкой PCRE; для форка добавьте angie -v.
Главное — найти опасную связку в конфигах. Поиск по каталогу /etc/nginx через grep с шаблоном «rewrite, цифровая ссылка $1/$2 и знак вопроса» вытащит подозрительные строки. Ложные срабатывания: переменные $host, $request_uri, $uri и именованные захваты вида (?P<name>...) в этот паттерн не попадают.
Затем проверьте ASLR командой cat /proc/sys/kernel/randomize_va_space. Значение 2 — полная рандомизация, 1 — частичная, 0 — защита выключена и риск выполнения кода максимальный. Если вернулся 0, включите её через sysctl и закрепите в /etc/sysctl.d, чтобы настройка пережила перезагрузку.
Последний шаг — следы в логах. Падение рабочего процесса с сигналом 11 (SIGSEGV) или 6 (SIGABRT) рядом с записями о рестарте воркера — тревожный признак. Сопоставьте его по времени со всплеском внешних запросов в error.log и системном журнале.
Эти проверки мы в IT For Prof прогоняем по всему парку серверов, а не только по «подозрительным»: уязвимость зависит от конфига, и сюрпризы вылезают там, где их не ждёшь.
Какие меры закрывают дыру без простоя
Главная мера — обновление до исправленной версии. F5 закрыла CVE-2026-42945 в nginx 1.30.1 (стабильная ветка) и 1.31.0 (mainline), а для NGINX Plus — в редакциях R36 P4 и R32 P6; связанная CVE-2026-9256 закрыта в 1.31.1. Точную версию под дистрибутив сверяйте по карточке вендора, потому что фиксы часто бэкпортируют без смены номера. Версии, дошедшие до конца поддержки, вендором не оценивались и считаются уязвимыми по умолчанию.
Перезагрузка и обновление бинарника nginx делаются без обрыва соединений — это его штатная возможность, так что оправдания «простой на патч» здесь нет.
Пока обновление не приехало в ваш дистрибутив, есть быстрая временная мера — заменить безымянные захваты на именованные:
~~rewrite ^/catalog/(.*)$ /index.php?path=$1 last;~~ → rewrite ^/catalog/(?P<path>.*)$ /index.php?path=$path last;
Знак вопроса в замене остаётся, но безымянный $1 исчезает — и уязвимость не срабатывает. Переменные $host, $request_uri, $uri трогать не нужно, они не захваты.
WAF подключайте как дополнительный рубеж, а не замену патча. Триггер сидит в вашей конфигурации, а не в одной легко сигнатурируемой строке запроса, поэтому отфильтровать все варианты эксплуатации на входе не выйдет. Рабочий порядок такой: сначала прицельно правим опасные rewrite-правила (минуты работы, эффект сразу), затем накатываем обновление по данным вендора и перезагружаемся без простоя, и только поверх держим WAF как страховку. Если не уверены, что сервер защищён — инженеры IT For Prof проверят конфигурацию nginx и закроют уязвимость без остановки сайта.
---
Заголовок: Как закрыть 18-летнюю дыру в nginx (CVE-2026-42945)
Теги: nginx, CVE-2026-42945, 1С-Битрикс, информационная безопасность, Angie