FoxIO обнаружила уязвимости отказа в обслуживании в нескольких реализациях HTTP/3 и опубликовала работающий код для проверки. Удалённому злоумышленнику не нужны учётная запись или специальные права: достаточно отправить небольшой объём сжатых заголовков. После распаковки они могут занять куда больше памяти. В Bun возможен другой исход: сервер зависает с загрузкой процессора на 100%.
Свидетельств кражи данных или выполнения кода исследователи не приводили. Публичных сообщений о реальных атаках тоже не было. Речь идёт именно об отказе в обслуживании.
HTTP/3 использует QPACK для сжатия заголовков запросов. Повторяющиеся поля можно передавать короткими ссылками вместо полного текста. Проблема возникает, если сервер ограничивает размер только сжатых данных, пришедших по сети, либо проверяет распакованный объём уже после обработки. Тогда скромный запрос способен разрастись до сотен тысяч записей заголовков в памяти.
Есть и второй способ усиления: сохранить запись заголовка размером около 4 КБ, а затем тысячи раз сослаться на неё однобайтовыми ссылками. Сервер восстанавливает полную запись для каждой ссылки. Поскольку HTTP/3 работает поверх UDP, запрос может добраться до сервера ещё до того, как сработает значительная часть привычных сетевых фильтров.
По состоянию на 22 октября 2026 года исправления выпустили quic-go версии 0.57.0 (CVE-2025-64702), Cloudflare quiche версии 0.29.3 (CVE-2026-12523), lsquic версии 4.9.0 и Wireshark версий 4.6.2 и 4.4.12 (CVE-2025-13945). В Bun, библиотеке h3 от hyperium и связке aioquic/mitmproxy на момент раскрытия уязвимостей исправлений не было; CVE для них не указаны. FoxIO обнаружила этот класс ошибок в семи из десяти проверенных стеков HTTP/3.
Не затронуты, по данным FoxIO, IIS, Envoy, ngtcp2/nghttp3 и quiche от Google. Эти реализации ограничивают объём распакованных заголовков прямо во время декодирования, а не после него.
В тестах с настройками по умолчанию пакет размером 1 МБ в quic-go превращался примерно в 160 000 полей заголовков и занимал в запросе около 15 МБ — приблизительно в 17 раз больше переданных данных. В собственном предупреждении quic-go возможное увеличение оценивается примерно в 50 раз. Для Bun FoxIO измерила усиление примерно в 4000 раз, для lsquic — от 600 до 1800 раз.
Последствия могут затронуть программы, которые используют эти библиотеки. quic-go лежит в основе Caddy, Traefik и cloudflared. Библиотека lsquic от LiteSpeed применяется в LiteSpeed Web Server и OpenLiteSpeed. HTTP/3-сервер Bun тоже построен на lsquic, но заменяет механизм ограничения памяти заголовков собственным кодом.
Документация Bun называет HTTP/3-сервер экспериментальным. По данным FoxIO, его код проверяет отдельные заголовки, но не ведёт общий счёт использованной ими памяти. Когда распакованный объём превышает 2 ГБ, счётчик переполняется и обнуляется, после чего сервер попадает в бесконечный цикл. Одного потока, передающего около 516 КБ по сети, достаточно, чтобы оставить процессор загруженным на 100% без восстановления и блокировать новые запросы. Собственный лимит lsquic в 64 КБ не позволяет довести ситуацию до переполнения.
Случай Wireshark устроен иначе: сбой происходит в HTTP/3-диссекторе, который разбирает трафик из захвата. Для него требуется расшифрованный трафик — например, при использовании файла с ключами или открытии захвата, содержащего секреты расшифровки. Это не уязвимость сервера, доступная для атаки через сеть. В Wireshark заявили: «Нам неизвестно о каких-либо эксплойтах для этой проблемы».
Операторам следует перейти на исправленные версии. Пока обновлений нет, FoxIO советовала не публиковать HTTP/3-сервер Bun, отключить HTTP/3 в mitmproxy командой
Работа FoxIO началась после исследования Гала Бар-Нахума (Gal Bar Nahum) о технике отказа в обслуживании «MadeYouReset», направленной против HTTP/2. Исследователи задались вопросом, может ли похожая слабость скрываться в сжатии заголовков HTTP/3. Исправление lsquic вышло 16 июля 2026 года: оно ограничивает число наборов распакованных заголовков, которые сервер хранит для одного потока; по умолчанию разрешён один набор.
Изображение носит иллюстративный характер
Свидетельств кражи данных или выполнения кода исследователи не приводили. Публичных сообщений о реальных атаках тоже не было. Речь идёт именно об отказе в обслуживании.
HTTP/3 использует QPACK для сжатия заголовков запросов. Повторяющиеся поля можно передавать короткими ссылками вместо полного текста. Проблема возникает, если сервер ограничивает размер только сжатых данных, пришедших по сети, либо проверяет распакованный объём уже после обработки. Тогда скромный запрос способен разрастись до сотен тысяч записей заголовков в памяти.
Есть и второй способ усиления: сохранить запись заголовка размером около 4 КБ, а затем тысячи раз сослаться на неё однобайтовыми ссылками. Сервер восстанавливает полную запись для каждой ссылки. Поскольку HTTP/3 работает поверх UDP, запрос может добраться до сервера ещё до того, как сработает значительная часть привычных сетевых фильтров.
По состоянию на 22 октября 2026 года исправления выпустили quic-go версии 0.57.0 (CVE-2025-64702), Cloudflare quiche версии 0.29.3 (CVE-2026-12523), lsquic версии 4.9.0 и Wireshark версий 4.6.2 и 4.4.12 (CVE-2025-13945). В Bun, библиотеке h3 от hyperium и связке aioquic/mitmproxy на момент раскрытия уязвимостей исправлений не было; CVE для них не указаны. FoxIO обнаружила этот класс ошибок в семи из десяти проверенных стеков HTTP/3.
Не затронуты, по данным FoxIO, IIS, Envoy, ngtcp2/nghttp3 и quiche от Google. Эти реализации ограничивают объём распакованных заголовков прямо во время декодирования, а не после него.
В тестах с настройками по умолчанию пакет размером 1 МБ в quic-go превращался примерно в 160 000 полей заголовков и занимал в запросе около 15 МБ — приблизительно в 17 раз больше переданных данных. В собственном предупреждении quic-go возможное увеличение оценивается примерно в 50 раз. Для Bun FoxIO измерила усиление примерно в 4000 раз, для lsquic — от 600 до 1800 раз.
Последствия могут затронуть программы, которые используют эти библиотеки. quic-go лежит в основе Caddy, Traefik и cloudflared. Библиотека lsquic от LiteSpeed применяется в LiteSpeed Web Server и OpenLiteSpeed. HTTP/3-сервер Bun тоже построен на lsquic, но заменяет механизм ограничения памяти заголовков собственным кодом.
Документация Bun называет HTTP/3-сервер экспериментальным. По данным FoxIO, его код проверяет отдельные заголовки, но не ведёт общий счёт использованной ими памяти. Когда распакованный объём превышает 2 ГБ, счётчик переполняется и обнуляется, после чего сервер попадает в бесконечный цикл. Одного потока, передающего около 516 КБ по сети, достаточно, чтобы оставить процессор загруженным на 100% без восстановления и блокировать новые запросы. Собственный лимит lsquic в 64 КБ не позволяет довести ситуацию до переполнения.
Случай Wireshark устроен иначе: сбой происходит в HTTP/3-диссекторе, который разбирает трафик из захвата. Для него требуется расшифрованный трафик — например, при использовании файла с ключами или открытии захвата, содержащего секреты расшифровки. Это не уязвимость сервера, доступная для атаки через сеть. В Wireshark заявили: «Нам неизвестно о каких-либо эксплойтах для этой проблемы».
Операторам следует перейти на исправленные версии. Пока обновлений нет, FoxIO советовала не публиковать HTTP/3-сервер Bun, отключить HTTP/3 в mitmproxy командой
--set http3=false, а для библиотеки h3 на Rust задать разумное ограничение через max_field_section_size. Работа FoxIO началась после исследования Гала Бар-Нахума (Gal Bar Nahum) о технике отказа в обслуживании «MadeYouReset», направленной против HTTP/2. Исследователи задались вопросом, может ли похожая слабость скрываться в сжатии заголовков HTTP/3. Исправление lsquic вышло 16 июля 2026 года: оно ограничивает число наборов распакованных заголовков, которые сервер хранит для одного потока; по умолчанию разрешён один набор.
