Два критических бага в nginx: use-after-free в HTTP/3 и heap overflow в gRPC-прокси

Представьте: ваш nginx работает на Ubuntu, обслуживает API-шлюз с HTTP/2-проксированием на микросервисы. Вы когда-то меняли ignore_invalid_headers off — чтобы пропускать нестандартные заголовки от одного из бэкендов — и увеличили large_client_header_buffers до 4 МБ под большие JWT. Всё работает, никаких проблем. А 17 июня 2026 года F5 выпустила внеплановый security advisory и выяснилось: именно ваша конфигурация позволяет удалённому атакующему без аутентификации крашить воркер-процессы nginx одним запросом. И это только один из двух критических багов, закрытых в тот день.

F5 описала шесть уязвимостей в продуктах NGINX-экосистемы. Два из них — критические RCE-класса, с CVSS v4.0: 9.2 каждый. CVE-2026-42530 — use-after-free в модуле ngx_http_v3_module, который обрабатывает HTTP/3 поверх QUIC. CVE-2026-42055 — heap-based buffer overflow в модулях HTTP/2-проксирования и gRPC-прохода. Оба позволяют неаутентифицированному удалённому атакующему вызвать краш воркер-процесса nginx, а на системах без ASLR или при его обходе — потенциально выполнить произвольный код. Оба закрыты в nginx 1.31.2, вышедшем в тот же день.

Активной эксплуатации на момент публикации не зафиксировано. Но это временное состояние: CVE-2026-42945 (NGINX Rift) в мае 2026 прошёл путь от публичного раскрытия до рабочего эксплойта в руках атакующих меньше чем за неделю. Рабочий PoC был реконструирован из diff патча практически мгновенно. У этих двух нет причин быть медленнее.

КАК РАБОТАЕТ БАГ В HTTP/3 (CVE-2026-42530)

HTTP/3 работает поверх транспортного протокола QUIC, который в отличие от TCP передаёт данные через несколько независимых потоков (streams) внутри одного соединения. Для сжатия заголовков в HTTP/3 используется механизм QPACK — он устроен сложнее чем HPACK из HTTP/2 именно потому, что QUIC-потоки могут приходить в произвольном порядке. QPACK использует два специальных контрольных потока: encoder stream (отправитель обновляет таблицу сжатия) и decoder stream (получатель подтверждает). По протоколу каждый из этих потоков открывается один раз на время соединения и не переоткрывается.

Баг в ngx_http_v3_module — в том, как nginx обрабатывает ситуацию, когда клиент в рамках уже существующего HTTP/3-соединения пытается открыть QPACK encoder stream повторно. При первом открытии nginx выделяет память под структуры данных потока. При закрытии — освобождает её. Когда клиент переоткрывает поток, nginx не проверяет корректно это граничное условие: воркер-процесс обращается к структурам данных, которые уже освобождены. Use-after-free (CWE-416) в классическом виде — чтение или запись в память, которая уже отдана аллокатору или передана под другой объект.

Затронуты только NGINX Open Source 1.31.0 и 1.31.1 — те версии, где поддержка HTTP/3 была добавлена или существенно переработана. Ветка 1.30.x не затронута. CWE-416 зафиксирован в официальном advisory F5 под номером NPS-8. Уязвимость обнаружена Trung Nguyen (@everping) из CyStack — его имя указано в официальном nginx changelog. F5 в advisory K000161616 дополнительно кредитует Zhenpeng (Leo) Lin (depthfirst), Evan Hellman (@xintenseapple) из Trail of Bits совместно с OpenAI, и команды AntAISecurityLab и Nebula Security (@nebusecurity).

КАК РАБОТАЕТ БАГ В HTTP/2-ПРОКСИ И gRPC (CVE-2026-42055)

Эта уязвимость требует трёх нестандартных параметров конфигурации одновременно. Первый: HTTP/2-проксирование включено через proxy_http_version 2 или используется директива grpc_pass. Второй: директива ignore_invalid_headers установлена в off. Третий: размер large_client_header_buffers превышает 2 мегабайта. По умолчанию все три параметра не создают проблемы — ignore_invalid_headers по дефолту on, а large_client_header_buffers по умолчанию 4 буфера по 8 КБ каждый.

Когда ignore_invalid_headers off, nginx перестаёт отфильтровывать заголовки с некорректными именами ещё на входе и передаёт их дальше — в том числе при формировании upstream-запроса. Модули ngx_http_proxy_v2_module и ngx_http_grpc_module строят заголовки upstream-запроса, копируя данные в heap-буфер. Размер этого буфера рассчитывается на основе предположения, что заголовки прошли валидацию. Когда large_client_header_buffers больше 2 МБ и валидация отключена — атакующий может отправить достаточно большие заголовки, чтобы копирование вышло за границы выделенного буфера. Heap-based buffer overflow (CWE-122) корраптит соседние аллокаторные метаданные или живые объекты в куче.

Уязвимость была обнаружена Mufeed VH из Winfunc Research — это имя появляется в официальном nginx.org changelog для версии 1.31.2. Затронуты nginx 1.13.10 — 1.31.1: это огромный диапазон версий, охватывающий почти десятилетие разработки. Патч вошёл в NGINX Open Source 1.31.2 (mainline) и 1.30.3 (stable), а для коммерческих продуктов — в NGINX Plus 37.0.2.1 и R36 P6.

КАК ЭТО ЭКСПЛУАТИРУЕТСЯ

Для CVE-2026-42530 (HTTP/3 UAF): атакующий устанавливает HTTP/3-соединение с сервером через UDP/443. Никакой предварительной аутентификации не требуется — QUIC-соединение само по себе публичное. Внутри соединения атакующий открывает QPACK encoder stream, закрывает его и затем открывает снова — действие, которое протокол запрещает, но которое nginx в версиях 1.31.0-1.31.1 обрабатывает некорректно. Воркер-процесс nginx обращается к уже освобождённым структурам данных и падает с memory corruption. Поскольку nginx автоматически перезапускает воркеры после краша, сервис восстанавливается — но повторные отправки пакета поддерживают DoS непрерывно.

Для CVE-2026-42055 (HTTP/2/gRPC heap overflow): атакующий отправляет HTTP-запрос с намеренно большими или некорректными заголовками — достаточно объёмными, чтобы превысить рассчитанный размер буфера при копировании в upstream-структуры. Проходная фильтрация отключена директивой ignore_invalid_headers off, поэтому заголовки попадают напрямую в heap-буфер модуля проксирования. Результат тот же: краш воркера, DoS.

Важная деталь из F5 advisory: «conditions beyond their control» — это намеренная формулировка. Она означает, что для срабатывания бага атакующий не может полностью контролировать все условия: нужны конкретные параметры конфигурации на стороне сервера. Именно поэтому уязвимость требует трёх специфических директив одновременно — это не просто «отправь большой заголовок», а «отправь большой заголовок на сервер, который намеренно отключил защиту и увеличил буфер». Тем не менее с точки зрения атакующего: если конфигурация совпадает — никаких технических барьеров нет. Один HTTP-запрос с раздутыми заголовками.

ЧТО ПРОИСХОДИТ ДАЛЬШЕ — ЗАВИСИТ ОТ КОНФИГУРАЦИИ

На системах с включённым ASLR (по умолчанию на всех современных Linux-дистрибутивах) оба бага надёжно дают DoS — краш и перезапуск воркер-процесса. ASLR рандомизирует адреса памяти при каждом запуске, что делает предсказуемое управление потоком выполнения после corruption существенно сложнее. Это не защита от краша, но от RCE — значительная, хотя и не абсолютная преграда.

На системах с отключённым ASLR или при его успешном обходе — а публичная видеодемонстрация CVE-2026-42530 уже существует и исследователи подтверждают реалистичность ASLR-bypass — memory corruption превращается в управляемый примитив. Heap overflow от CVE-2026-42055 корраптит соседние аллокаторные метаданные или живые объекты — стандартный путь к control-flow hijacking по оценке независимых исследователей. Use-after-free от CVE-2026-42530 даёт примитив чтения/записи в освобождённую память — аналогичный исходный материал. F5 явно указывает в advisory обоих CVE: на системах без ASLR или при его обходе возможно выполнение произвольного кода.

Важная деталь из официального changelog nginx.org: CVE-2026-48142 (buffer overread в ngx_http_charset_module, закрытый в том же 1.31.2) официально описан как «limited disclosure of worker process memory». Исследователи из thecybersecguru.com указывают, что именно такая утечка памяти воркера является классическим инструментом для обхода ASLR перед запуском CVE-2026-42530 или CVE-2026-42055. Это их оценка, не официальное заявление F5. Все три CVE закрываются одним обновлением до 1.31.2.

ХРОНОЛОГИЯ

17 июня 2026 — F5 выпускает внеплановый security advisory K000161614, описывающий шесть CVE в продуктах NGINX-экосистемы. Одновременно публикуются nginx 1.31.2 (mainline) и 1.30.3 (stable) с патчами. «Внеплановый» здесь ключевое слово: F5 обычно выпускает security bulletins по квартальному расписанию. Отклонение от него означает, что ждать следующего цикла было нельзя.

19 июня 2026 — SecurityLab и Хакер публикуют новости. На официальном сайте nginx.org появляется обновлённый список security advisories с шестью новыми позициями. На момент публикации этой статьи активной эксплуатации CVE-2026-42530 и CVE-2026-42055 не зафиксировано, PoC публично не опубликован. По данным SOCRadar, исследователи отслеживают CVE-2026-42530 под неофициальным названием nginx-quicburst, и публичная видеодемонстрация бага уже существует — это сигнал, что техническое понимание уязвимости вышло за пределы группы авторов-исследователей.

ПОЧЕМУ ЭТО ВАЖНО

Оба бага — network-exploitable, unauthenticated, без какого-либо взаимодействия с пользователем. Это максимально благоприятные условия для атакующего: достаточно IP-доступа до вашего nginx на порту 443. Не нужно угадывать пароль, эксплуатировать уязвимость в CMS, или ждать пока кто-то кликнет на ссылку. Один UDP-пакет — воркер упал.

Путаница с CVSS-баллами здесь реальная — и её стоит понять. CVE-2026-42530 и CVE-2026-42055 получили три разных оценки в зависимости от источника: CVSS v3.1 — 8.1 (High, по данным CSA Singapore и Tenable), CVSS v4.0 — 9.2 (Critical, по данным F5 advisory), и внутренний рейтинг nginx.org — «major» и «medium» соответственно. Все три корректны, они просто измеряют разное. CVSS v4 изменил формулу расчёта для network-exploitable memory-corruption багов и стал давать им более высокие оценки, чем v3.1. Рейтинг nginx.org отражает собственную оценку команды об надёжности эксплуатации — исторически более консервативную. Если ваша vulnerability management система ориентируется только на одну шкалу, вы можете получить «medium» и «critical» для одного и того же бага в зависимости от источника. Ориентируйтесь на CVSS v4.0: 9.2 как на более современную и точную оценку.

CVE-2026-42055 затрагивает nginx 1.13.10 — 1.31.1. Версия 1.13.10 относится к 2017–2018 годам разработки. Почти десятилетие уязвимого кода — при условии, что конфигурация совпадает. «Специфическая конфигурация» здесь не означает «экзотическая»: HTTP/2-проксирование с нестандартными заголовками и увеличенными буферами — это ровно то, что делают при обслуживании gRPC-трафика, крупных JWT и нестандартных API-схем. Production с микросервисами.

ОБНОВЛЕНИЕ

Проверьте текущую версию nginx — она покажет, на mainline или stable ветке вы находитесь и нужно ли обновляться:

nginx -v

Если вывод показывает 1.31.0 или 1.31.1 — вы уязвимы к CVE-2026-42530 и CVE-2026-42055. Если любая версия от 1.13.10 до 1.31.1 — к CVE-2026-42055. Обновитесь до 1.31.2 (mainline) или 1.30.3 (stable). На Ubuntu/Debian, если nginx установлен из официального репозитория nginx.org — команда обновит до актуальной версии:

apt update && apt install nginx

Если nginx установлен из стандартного репозитория дистрибутива (например, Ubuntu universe) — там может быть старая версия, не получившая патч. Проверьте откуда пришёл пакет: apt-cache policy nginx. Если видите адрес вида nginx.org/packages — всё в порядке. Если адрес дистрибутива — проверьте версию и при необходимости переключитесь на официальный репозиторий nginx.org.

На RHEL/CentOS/AlmaLinux используйте dnf — команда обновит nginx до последней доступной версии в подключённых репозиториях:

dnf update nginx

После обновления убедитесь что запущена новая версия — вывод должен показать 1.31.2 или 1.30.3:

nginx -v && systemctl status nginx

Если немедленное обновление невозможно — используйте временные меры. Они снижают risk, но не заменяют патч: обновитесь при первой возможности. Для CVE-2026-42530: отключите HTTP/3, убрав параметр quic из всех директив listen. Это полностью устраняет attack surface, потому что уязвимость недостижима без HTTP/3. Убедитесь что quic не осталось нигде в конфигурации — команда выведет все строки где встречается это слово:

grep -r "quic" /etc/nginx/

Если в выводе есть строки вида listen 443 quic reuseport; или http3 on; — именно эти строки нужно закомментировать или удалить, после чего перезагрузить nginx. Если вывод пустой — HTTP/3 не включён, CVE-2026-42530 вас не касается.

Для CVE-2026-42055: восстановите дефолтное значение ignore_invalid_headers (то есть on) или уменьшите large_client_header_buffers ниже 2 МБ. Одного из двух достаточно — уязвимость требует оба условия одновременно. Проверьте что в конфиге есть проблемные директивы:

grep -r "ignore_invalid_headers\|large_client_header_buffers" /etc/nginx/

Если строк нет — уязвимость CVE-2026-42055 вас не касается при дефолтных настройках. Если строки есть — проверьте значения: ignore_invalid_headers off вместе с large_client_header_buffers больше 2 МБ это уязвимая конфигурация. После любых изменений — проверка синтаксиса и перезагрузка:

nginx -t && systemctl reload nginx

ВЫВОДЫ

Два critical-класса бага в nginx в один день — это не рядовое событие, и внеплановый advisory от F5 это подтверждает. CVE-2026-42530 затрагивает узкий, но быстро растущий сегмент — тех, кто включил поддержку HTTP/3 в 1.31.x. CVE-2026-42055 покрывает огромный диапазон версий — 1.13.10 — 1.31.1 — при нестандартной, но практически распространённой конфигурации.

Все три уязвимости — CVE-2026-42530, CVE-2026-42055 и CVE-2026-48142 — закрываются одним обновлением до 1.31.2. Патч существует, он стабилен, он вышел одновременно с advisory. Если вы на Debian/Ubuntu с nginx.org репозиторием — обновитесь прямо сейчас. На RHEL/AlmaLinux — аналогично через dnf. История с NGINX Rift показала, что окно между «патч вышел» и «эксплойт в дикой природе» измеряется днями, а не неделями. Команды обновления и проверки результата есть в секции ОБНОВЛЕНИЕ выше.