Если вы используете nginx как reverse proxy с включённым HTTP/3, релиз 1.31.6 от 15 сентября 2026 - это не рутинное обновление, а security-фикс, который стоит прочитать целиком, а не пробежать по диагонали. Релиз закрывает CVE-2026-90439 - heap buffer overflow в HTTP/3-коде (ngx_http_v3_module), который срабатывает только если nginx собран с OpenSSL 3.5.0 или ниже.[1] Если вы на дистрибутивном nginx со старым OpenSSL и включили раздачу QUIC, уязвимый код сидит в worker-процессе прямо перед вашим трафиком.

Обновление, 17 октября 2026: 1.31.6 / 1.30.5 - уже не целевые версии. 14 октября 2026 nginx выпустил 1.31.7 (mainline) и 1.30.6 (stable), которые закрывают ещё пять CVE средней серьёзности (CVE-2026-15176, CVE-2026-93479, CVE-2026-95101, CVE-2026-97629, CVE-2026-97205), затрагивающих в том числе 1.31.6 и 1.30.5; одна из них (CVE-2026-95101) - снова в обработке тела запроса в HTTP/3.[3][6] Проверки ниже для CVE-2026-90439 остаются в силе, но обновляйтесь сразу до 1.31.7 / 1.30.6.

Это дополнение к нашему гайду по конфигурации reverse proxy и гайду по Control API - здесь мы исходим из того, что nginx у вас уже работает. Дальше - минимум, который нужно знать о самой дыре, как проверить, попадает ли ваш хост под удар, и точные шаги, чтобы выйти из-под него.

Что такое CVE-2026-90439

CVE-2026-90439 - это heap buffer overflow в модуле, который обеспечивает HTTP/3 - ngx_http_v3_module, запускающий HTTP/3 поверх транспорта QUIC. Переполнение может возникнуть, пока nginx обрабатывает TLS-рукопожатие, если сборка использует OpenSSL <= 3.5.0, при определённых конфигурациях.[2]

Про него важно понимать две вещи, потому что они определяют, насколько это срочно:

  • Это нельзя надёжно превратить в эксплойт. В записи CVE прямо сказано, что переполнение «может произойти недетерминированным образом, вне контроля атакующего».[2] Это не чисто универсальный примитив для удалённого выполнения кода; на практике оно обычно проявляется как рестарт worker-процесса (denial of service) или, в худшем случае, ограниченное повреждение данных в воркере.
  • Это только data plane. Влияния на control plane нет; удалённый атакующий может направить на уязвимый сервер специально сформированное рукопожатие, чтобы вызвать DoS или ограниченное повреждение данных, но адвайзори не описывает пути к control plane.[2]

Серьёзность - medium на странице адвайзори nginx, F5 оценивает её как CVSS 6.5 (3.1) / 6.9 (4.0) - доступ из сети, низкая сложность, без привилегий, без взаимодействия с пользователем.[2][3] То есть да, «medium», но оно удалённо достижимо на веб-сервере, говорящем по HTTP/3. Для reverse proxy с открытым QUIC это ровно та зона поражения, которую не стоит оставлять открытой.

Какие версии в зоне риска

Из адвайзори nginx:[3]

  • Уязвимы: nginx 1.29.2–1.31.5 (mainline).[3] На стабильной ветке в зоне риска всё, что ниже 1.30.5, - CVE-запись указывает 1.30.4 как затронутую стабильную сборку.[2]
  • Не уязвимы: 1.31.6+ и 1.30.5+.

Две ветки, один фикс: nginx выпустил 1.31.6 (mainline) и 1.30.5 (stable) в один день, с одинаковой security-заметкой - «heap memory buffer overflow может возникнуть в worker-процессе при определённых конфигурациях при использовании HTTP/3 с OpenSSL 3.5.0 и ниже (CVE-2026-90439)».[1]

Зону риска сужает ещё одно условие: HTTP/3 должен быть реально собран и включён. ngx_http_v3_module не собирается по умолчанию - его включают на этапе сборки флагом --with-http_v3_module.[4] Значит, стоковый дистрибутивный nginx, который никогда не был собран с этим модулем, эту дыру не встретит, даже если номер версии выглядит уязвимым. Переполнению нужны модуль v3, HTTP/3, согласованный хотя бы на одном server-блоке, и уязвимый OpenSSL.

Затронут ли мой хост? Проверьте эти три вещи

Не рассуждайте по памяти - считывайте с машины. Три быстрые команды всё покрывают.

1. Какая у вас версия nginx?

nginx -v
# nginx version: nginx/1.31.5   → в зоне риска (mainline)
# nginx version: nginx/1.30.5   → этот CVE закрыт, но обновитесь до 1.30.6 (CVE октября 2026)

2. Был ли собран HTTP/3-модуль?

nginx -V 2>&1 | grep -o '\-\-with-http_v3_module'

Если ничего не вывело - модуль не скомпилирован, и через HTTP/3 эта CVE до вас не дотянется. Обновить всё равно стоит, но срочность резко падает.

3. С каким OpenSSL собран nginx?

nginx -V 2>&1 | grep -iE 'openssl|OpenSSL'
openssl version

nginx -V печатает OpenSSL, с которым он собран (например, built with OpenSSL 3.5.0). CVE требует OpenSSL <= 3.5.0.[2] Если nginx собран с OpenSSL 3.5.1 или новее, уязвимый путь не активен даже на подпадающей под версии сборке nginx.

Здесь важен именно код HTTP/3 в пути, связанном с OpenSSL - то есть версия связанного OpenSSL, а не то, что говорит системный openssl version. На стандартной дистрибутивной установке они обычно совпадают, но проверяйте оба и доверяйте nginx -V.

4. Включён ли HTTP/3 в конфиге? (если модуль собран)

grep -rnE 'listen .*(quic|http3)' /etc/nginx/sites-enabled/
grep -rn 'http3' /etc/nginx/

HTTP/3 раздаётся, когда в server-блоке есть listen 443 quic reuseport; (или listen ... http3;) - именно так настраивает его собственный пример модуля.[4] Если у вас где-то есть listen ... quic, а проверки версии и OpenSSL выше говорят, что вы уязвимы, - вы в зоне риска прямо сейчас.

Полный профиль под ударом узок, но реален: nginx 1.29.2–1.31.5 (или стабильный ниже 1.30.5) + собранный --with-http_v3_module + listen ... quic в конфиге + OpenSSL <= 3.5.0. Это прокси, который реально говорит по HTTP/3 и собран с докритическим OpenSSL.

Апгрейд: пропатченные релизы обеих веток

Обе исправленные версии вышли 15 сентября 2026 и доступны в исходниках и в обычных бинарных пакетах.[1][5] Апгрейд - та же рутина, что и любой security-бамп nginx. Секция ниже предполагает, что вы получили 1.31.6 (или 1.30.5) из репозитория, а не собирали вручную.

# Debian / Ubuntu
sudo apt update
sudo apt install nginx=1.31.7*          # mainline с security-фиксом (14.10.2026; 1.31.8 тоже подходит); или просто `sudo apt upgrade`

Если ваш дистрибутив закрепляет более старый стабильный nginx (частая ситуация - Ubuntu поставляет старые стеки mainline/stable), у вас есть два реальных варианта: переехать на официальные пакеты nginx.org нужной ветки или собрать с более новым OpenSSL. В документации модуля сказано, что HTTP/3 требует OpenSSL 1.1.1 или выше, а поддержка 0-RTT - OpenSSL 3.5.1 или выше.[4] Этот порог 3.5.1+ для 0-RTT удобное совпадение: OpenSSL на уровне 3.5.1 или выше - ровно та сборка, которая лежит вне затронутого диапазона OpenSSL этой CVE.

Проверьте конфиг перед тем, как трогать работающий процесс. Совет из гайда по Control API остаётся в силе: сначала протестируйте кандидатный конфиг.

sudo nginx -t           # сначала проверяем, что конфиг парсится чисто

Затем reload или restart. Для security-фикса однозначный выбор - restart с новым бинарником: reload во время смены продолжает обслуживать новые соединения старым бинарником и переводит воркеры только по сигналу. Для смены конфига это нормально; для security-патча вы хотите, чтобы пропатченный бинарник реально терминировал соединения.

# чище всего для security-патча: полный restart
sudo systemctl restart nginx

# или, если уверены в себе и хотите zero-downtime пересоздание воркеров
sudo systemctl reload nginx

Подтвердите версию, которая теперь обслуживает:

nginx -v
# nginx version: nginx/1.31.7
nginx -V 2>&1 | grep -iE 'openssl'
# built with OpenSSL 3.5.0   ← `nginx -V` - правда о связанной библиотеке

Если после обновления пакета nginx nginx -V всё ещё показывает старый OpenSSL - ваш дистрибьютор пересобрал nginx против дистрибутивного OpenSSL, а не приложил новый. В этом случае именно фикс на стороне nginx в 1.31.6/1.30.5 закрывает CVE, так что меняться должна версия nginx.

Вместе с обоими релизами приходит ещё одно изменение поведения, о котором стоит знать даже после патча: «теперь расширение параметров транспорта QUIC, полученное в SSL-соединении, всегда игнорируется».[1] Это небольшое укрепление, закрывающее вектор путаницы на границе TLS/QUIC-рукопожатия в той же зоне.

Не можете обновиться прямо сейчас? Отключите HTTP/3

Честный ответ: единственное исправленное состояние - это пропатченный nginx (или OpenSSL выше 3.5.0). Но уязвимый код работает только там, где server-блок реально согласовывает HTTP/3. Если немедленно обновить бинарник nginx нельзя, самое большое, что можно сделать - перестать раздавать HTTP/3 сегодня:

# до (уязвимый путь активен там, где согласовывается HTTP/3)
# listen 443 quic reuseport;
# listen 443 ssl;

# после (HTTP/3 выключен; клиенты откатываются на HTTP/2 / HTTP/1.1)
# listen 443 ssl;

Закомментируйте (или удалите) параметр quic в строке listen и уберите любую директиву http3 on;, оставив обычный блок listen 443 ssl;, который уже обслуживал TLS. Выполните nginx -t, затем reload. Клиенты, которые хотели говорить по HTTP/3, теперь согласовывают HTTP/2; уязвимый путь рукопожатия больше недостижим.

Это сознательное снижение поддержки протокола, поэтому взвесьте, какая доля клиентов реально садится на HTTP/3 - для большинства сайтов это небольшая часть, и HTTP/2 отлично закрывает остальное. Ровно так устроен server-блок в нашем гайде по reverse proxy - там listen 443 ssl; + http2 on; и никакого QUIC.

Две честные оговорки про путь «отключить»:

  • Это митигация, а не фикс. Как только вы снова включите quic, уязвимый путь вернётся, пока не пропатчен nginx (или связанный OpenSSL). Отключение HTTP/3 - временная мера, финальная точка - апгрейд.
  • Не выдумывайте полумер. Адвайзори не благословляет никакой «безопасный поднабор» настроек HTTP/3 для уязвимых сборок nginx+OpenSSL. Либо вы тестируете и патчите, либо убираете HTTP/3, пока не сможете обновиться. Не оставляйте quic-листенер, думая, что меньший буфер или меньше стримов сделает его безопасным - переполнение в пути рукопожатия, и его не выкрутить настройками.

К чему это относится

Фикс лежит в той же линейке релизов, что и фичи, которые разбирают наши другие гайды: 1.31.5 добавил Control API и predicate locations, а 1.31.6 укрепляет HTTP/3-сторону поверх правильно настроенного reverse proxy. Если вы берёте новые фичи mainline, вы всё равно на mainline-ветке, а значит фикс 1.31.6 - в одном apt upgrade.

Короткая версия

CVE-2026-90439 - heap buffer overflow средней серьёзности в HTTP/3-модуле nginx, достижимый удалённо, который срабатывает только если nginx собран с OpenSSL 3.5.0 или ниже. Затронуты: nginx 1.29.2–1.31.5 (mainline) и 1.30.x ниже 1.30.5 (stable), при условии что модуль v3 собран, HTTP/3 включён в конфиге и OpenSSL <= 3.5.0. Если это ваш хост - обновитесь - сегодня это 1.31.7 или 1.30.6, где есть и этот фикс, и пять CVE октября 2026[6]: проверьте nginx -t, сделайте restart, подтвердите через nginx -v и nginx -V. Если правда не можете обновиться - отключите HTTP/3 (уберите quic из listen) и дайте клиентам откатиться на HTTP/2, пока не пропатчитесь. Не оставляйте уязвимый quic-листенер работать, пока думаете.

Источники

  1. nginx - Changes (релиз 1.31.6, 15.09.2026: заметка про CVE-2026-90439; изменение QUIC transport-parameters). https://nginx.org/en/CHANGES - проверено 2026-09-30
  2. Запись CVE-2026-90439 (описание, затронутый OpenSSL <= 3.5.0, недетерминированное переполнение, DoS/ограниченное повреждение, CVSS). https://www.cve.org/CVERecord?id=CVE-2026-90439 - проверено 2026-09-30
  3. nginx - Security advisories (затронуты 1.29.2–1.31.5, не уязвимы 1.31.6+/1.30.5+; серьёзность medium). https://nginx.org/en/security_advisories.html - проверено 2026-09-30
  4. nginx - Module ngx_http_v3_module (--with-http_v3_module, не собирается по умолчанию, listen ... quic, OpenSSL 1.1.1+ / 0-RTT 3.5.1+). https://nginx.org/en/docs/http/ngx_http_v3_module.html - проверено 2026-09-30
  5. nginx - download (исходники и бинарные пакеты; mainline 1.31.x / stable 1.30.x). https://nginx.org/en/download.html - проверено 2026-09-30
  6. nginx - Changes with nginx 1.31.7 / 1.30.6 (14.10.2026: CVE-2026-15176, CVE-2026-93479, CVE-2026-95101, CVE-2026-97629, CVE-2026-97205; по странице advisories не уязвимы 1.31.7+/1.30.6+). https://nginx.org/en/CHANGES ; https://nginx.org/en/security_advisories.html - проверено 2026-10-17