NGINX закрыл пять уязвимостей, включая возможный RCE и обход проверки клиентских сертификатов

Разработчики NGINX выпустили 14 октября версии 1.30.6 (стабильная ветка) и 1.31.7 (mainline), закрыв пять уязвимостей. Одна из них присутствовала в каждом релизе начиная с мая 2005 года.

Три из пяти — ошибки работы с памятью в рабочем процессе. По словам F5, компании-владельца NGINX, они могут привести к падению процесса или, в отдельных конфигурациях, к выполнению кода. NGINX оценивает все пять проблем как средние по уровню риска, однако F5 по шкале CVSS v4.0 выставляет трём «памятным» уязвимостям по 9,2 (критический уровень), проблеме с TLS — 8,3, а недостатку в HTTP/3 — 6,9. Ни одна из уязвимостей не числится в каталоге активно эксплуатируемых CISA, и ни NGINX, ни F5 не сообщают об атаках.

Что нужно для эксплуатации

Каждая из уязвимостей срабатывает лишь при определённой конфигурации: alias в связке с rewrite, регулярное выражение в map, aio вместе с SSI, общий кэш TLS-сессий или HTTP/3. Неприятно, что ряд этих настроек рекомендует сама документация NGINX, а буферизация запросов для HTTP/3 включена по умолчанию.

TLS: третий ключ из неинициализированной памяти

Самая любопытная ошибка (CVE-2026-97629) кроется в автоматической ротации ключей для session ticket. С версии 1.23.2 (октябрь 2022) при общем кэше сессий NGINX сам генерирует и обновляет три ключевых слота, если ключи не загружены из файла. Каждый рабочий процесс хранит копию трёх слотов, но при ротации копировались только два — в третьем оставался мусор из памяти. Тикет, ссылающийся на этот слот, можно было проверить и расшифровать неинициализированным материалом, что открывает возможность подделки сессии. F5 подчёркивает, что подделка «недетерминирована и вне контроля атакующего», но в теории позволяет обойти проверку клиентских сертификатов. Уязвимую настройку ssl_session_cache shared:SSL:10m приводит в пример сама документация.

Один дефект родом из июля

Ошибка в map (CVE-2026-93479) возникла в коде обработки строк, который чинили 15 июля для другой уязвимости. Июльский патч защитил от переполнения буфера, но данные всё равно могли «протечь» в зарезервированную область, а последующий размер строки считался уже с учётом этой утечки. Ещё в июле исследователь Стэн Шоу предупреждал The Hacker News, что переход на именованные группы оставляет узкий путь открытым, а единственным полным решением остаётся обновление.

Недостаток HTTP/3 (CVE-2026-95101) связан с тем, что одно поле парсера выполняло две роли: хранило остаток длины пропускаемого неизвестного кадра и число байтов тела. Когда кадр разрывался между чтениями, остаток уходил на бэкенд в обход client_max_body_size.

Что делать

Следует обновиться до 1.30.6 или 1.31.7; патчи выходят только для этих двух веток, поэтому старые (например, 1.28) остаются уязвимыми. Увидеть включённые опции помогает nginx -T. Это уже восьмой релиз безопасности NGINX в 2026 году — а майскую ошибку в модуле rewrite, по данным VulnCheck, начали эксплуатировать уже через несколько дней после раскрытия.

Источник: The Hacker News