NGINX закрыл пять уязвимостей: обновитесь до 1.30.6 или 1.31.7

14 октября 2026 года NGINX выпустил версии 1.30.6 (stable) и 1.31.7 (mainline). Они закрывают пять уязвимостей: три ошибки работы с памятью в рабочих процессах, проблему с HTTP/3 и ошибку в TLS-сессиях, из-за которой в отдельных конфигурациях может не сработать проверка клиентского сертификата. Это восьмой выпуск безопасности NGINX за 2026 год. Если сайт, CRM или API стоит за nginx, это касается вас.

Что произошло

Сам проект nginx.org оценивает все пять уязвимостей как средние. F5, которой принадлежит NGINX, считает иначе: три ошибки памяти получили 9,2 по CVSS 4.0, то есть критический уровень, ошибка TLS — 8,3, проблема HTTP/3 — 6,9. Разница объясняется тем, что для атаки нужна определённая конфигурация. На 15 октября ни одна уязвимость не попала в каталог эксплуатируемых CISA, атак ни NGINX, ни F5 не фиксировали.

Важная деталь: CVE-2026-93479 появилась из-за июльского исправления другой уязвимости, CVE-2026-42533. Сервер, который вы честно обновили в июле, всё ещё в зоне риска.

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

Почти всех, кто держит сайт на своём VPS или выделенном сервере. Типовые сборки «nginx перед PHP-FPM» или «nginx перед Node.js» используют alias, rewrite и map постоянно. HTTP/3 включают реже, но он всё чаще идёт в шаблонах панелей.

Ошибка с TLS-сессиями важна тем, у кого nginx проверяет клиентские сертификаты (mTLS): закрытые API для партнёров, доступ к админке по сертификату. F5 пишет, что сбой недетерминированный и атакующий им не управляет, но полагаться на такую проверку до обновления не стоит.

Если вы на виртуальном хостинге, nginx обновляет провайдер. Спросите поддержку, какая версия стоит и когда будет обновление.

Что делать

1. Узнайте версию: команда `nginx -v`. Сверьте её в калькуляторе ниже или с таблицей на nginx.org.
2. Обновитесь до 1.30.6 или 1.31.7. Ветки ниже 1.30 nginx.org больше не исправляет, их нужно переводить на поддерживаемую.
3. Если ставите nginx из пакетов Debian, Ubuntu или RHEL, номер версии может остаться старым, а исправления придут бэкпортом. Проверяйте бюллетень дистрибутива, а не только цифры.
4. Если обновить сразу нельзя, выгрузите полный конфиг командой `nginx -T` и найдите опасные сочетания из таблицы. Для каждой уязвимости F5 дала обходной путь: отключить aio или SSI, выключить proxy_request_buffering для HTTP/3, задать ключи сессий через ssl_session_ticket_key.
5. После обновления выполните `nginx -t` и мягкий перезапуск. Проверьте сайт, формы и API.

Как устроены уязвимости простыми словами

Подробности нужны не для атаки, а чтобы понять, проверять ли свой конфиг.

alias и rewrite. Директива alias подменяет путь к файлам, а rewrite меняет адрес запроса. Ошибка возникает в короткий момент, когда адрес уже изменён, а nginx ещё не выбрал следующий блок location. Эту уязвимость F5 нашла сама.

map с регулярным выражением. Если захваченные части регулярки используются в root или в формате журнала раньше, чем переменная из map, память может быть перезаписана. В качестве обхода F5 советует именованные захваты и только внутри блока сопоставления.

aio и SSI. Счётчик незавершённых асинхронных операций был восьмибитным и без проверки на переполнение. После 256 операций он обнулялся, и запрос освобождался, пока на него ещё ссылались.

HTTP/3. Одно поле парсера использовалось для двух целей. Остаток неизвестного кадра мог уйти бэкенду как часть тела запроса и обойти лимит client_max_body_size.

TLS-сессии. При автоматической смене ключей сессионных билетов копировались два слота из трёх, в третьем могли остаться неинициализированные данные. Конфигурация с `ssl_session_tickets off` не затронута.

Что ещё вышло в тот же день

Вместе с nginx обновился модуль njs до версии 1.0.2: исправлены две средние уязвимости в обработке XML, CVE-2026-101025 и CVE-2026-101019. Если вы используете njs для логики на уровне сервера, обновите и его.

Пользователям NGINX Plus и продуктов F5 (Ingress Controller, Gateway Fabric, Instance Manager, WAF) нужно смотреть отдельные бюллетени F5. Для части этих продуктов на 15 октября исправленных сборок ещё не было.

Наше мнение

Восемь выпусков безопасности за десять месяцев — это новая норма для веб-сервера, а не исключение. Мы советуем клиентам держать обновление nginx в ежемесячном регламенте и проверять не только версию, но и вывод `nginx -T`: половина уязвимостей года срабатывает только при определённых директивах. Если сервер ведёт подрядчик, попросите его подтвердить версию письменно. Так же стоит проверить и PHP: недавняя история с PHP2Shell показала, что атаки начинаются раньше официальных патчей.