Исследователь безопасности Себастьен Фери из компании FoxIO нашёл в библиотеке XQUIC — той самой, что Alibaba написала для работы с QUIC и HTTP/3 — баг, который не требует ни поддельных пакетов, ни авторизации, ни каких-то экзотических условий. Достаточно отправить обычный, полностью легитимный трафик QPACK объёмом около 260 байт, и процесс сервера падает. Фери раскрыл уязвимость 8 июля, публично назвал её XRING, а к 10 июля патча так и не появилось — как и номера CVE.
Проблема сидит в коде с января 2022 года, то есть с самого первого публичного релиза XQUIC. За это время библиотека прошла через все версии вплоть до текущей 1.9.4 — и баг остался нетронутым во всех них. Поскольку XQUIC распространяется как открытый исходный код, любой сервер, который встроил её с настройками QPACK по умолчанию, уязвим. FoxIO прямо называет один конкретный продукт — Tengine, веб-сервер Alibaba на основе Nginx, который, по их данным, стоит перед облачной и CDN-инфраструктурой компании. В числе затронутых сайтов упомянуты Taobao и Alipay.
Чтобы понять суть бага, придётся немного углубиться в механику HTTP/3. Протокол использует QPACK для сжатия заголовков — чтобы не гонять по сети одно и то же значение user-agent в каждом запросе. Для этого QPACK держит общую динамическую таблицу, которую строит через отдельный канал управления — encoder stream. И именно клиент указывает серверу, как эту таблицу растить или уменьшать.
XQUIC хранит байты таблицы в кольцевом буфере — блоке фиксированной памяти, где данные при заполнении заворачиваются с конца на начало. Когда клиент просит таблицу увеличить, происходит три шага: выделяется буфер побольше, старые данные копируются в новый, а логика копирования разбита на четыре случая — в зависимости от того, где именно заворачиваются данные: в старом буфере, в новом, в обоих сразу или нигде. Баг живёт ровно в одном из этих четырёх случаев: там остаточные «хвостовые» байты меряются относительно ёмкости нового, большего буфера, вместо того чтобы мериться относительно ёмкости старого. Разница в размерах превращается в серьёзный перерасчёт не в ту сторону.
Фери привёл конкретный пример. Берём таблицу на 64 байта с курсором записи почти у самого конца, растим её до 65 байт — и XQUIC высчитывает, что нужно перенести 70 хвостовых байт. Реальное число — 6. Расхождение в разы.
Дальше это неверное, завышенное число попадает в операцию копирования памяти. Длина копирования вычисляется как разность между этим числом и меньшей величиной. Поскольку тип данных — беззнаковый size_t, вычитание уходит в underflow и оборачивается почти в максимальное значение переменной. В итоге операция копирования пытается пройти далеко за границы отведённой памяти.
Фери тестировал это на релизной сборке FoxIO под Ubuntu 26.04. Там сработала защита glibc — флаг _FORTIFY_SOURCE=2, который поймал некорректную длину и убил процесс, то есть просто произошёл крах программы. Но без этой защиты копирование пошло бы за пределы буфера уже не с падением, а с реальной записью данных из старого буфера за конец нового. Важная деталь: Фери показал именно крах сервера, но не проверял, можно ли эту порчу памяти развить дальше — например, в удалённое исполнение кода.
Ключевое здесь то, что ни одно из значений в атаке не нарушает правила протокола QPACK. Лимит XQUIC на динамическую таблицу по умолчанию — 16 килобайт. Вредоносная нагрузка запрашивает всего 64 байта, потом 65 — что укладывается в лимит с огромным запасом. Атакующему нужно лишь подвести таблицу к точной конфигурации заворота, при которой срабатывает бракованная ветка кода. Никаких битых пакетов, никакой аутентификации — только штатное поведение протокола, доведённое до нужного состояния.
Официального патча пока нет, поэтому речь идёт о двух обходных вариантах. Первый — выставить SETTINGS_QPACK_MAX_TABLE_CAPACITY в 0, что отключает динамическую таблицу QPACK целиком. Второй — банально отказаться от поддержки HTTP/3.
Похожие истории с падением серверов на HTTP/2 и HTTP/3 всплывали и раньше. За три недели до раскрытия XRING издание The Hacker News писало о CVE-2026-42530 — use-after-free в HTTP/3-модуле NGINX, достижимом удалённо и без авторизации через тот же самый encoder stream QPACK. В июне исследователь под псевдонимом Calif обнаружил атаку под названием HTTP/2 Bomb, эксплуатирующую HPACK — предшественника QPACK по части сжатия заголовков в HTTP/2; от неё досталось Nginx, Apache, IIS и Envoy. В феврале в HAProxy нашли две проблемы с крахами при обработке QUIC, одна из которых — целочисленный underflow при валидации токена, тот же класс бага, что и у XRING. Разница принципиальная: там атаке требовался испорченный пакет, здесь — нет.
Именно в этом The Hacker News видит главную особенность XRING: не поддельный трафик и не сложная цепочка эксплойтов, а простая арифметическая ошибка в сочетании с абсолютно легальными входными данными, которая укладывает сервер наповал. Издание направило вопросы обеим сторонам. У Alibaba спрашивают, готовится ли исправление и присвоение CVE, а также дошли ли до её команды безопасности пять попыток раскрытия, которые предприняла FoxIO. У самой FoxIO хотят узнать, фиксировались ли попытки эксплуатации в реальном мире и можно ли превратить эту порчу памяти в куче во что-то более серьёзное, чем банальный крах процесса.
На момент 10 июля CVE не присвоен, патча не существует, подтверждённых случаев эксплуатации в дикой природе, по данным FoxIO, не зафиксировано. Показан только крах сервера — не удалённое исполнение кода. История помечена как развивающаяся, и материал обещают обновить после ответов Alibaba и FoxIO.
Проблема сидит в коде с января 2022 года, то есть с самого первого публичного релиза XQUIC. За это время библиотека прошла через все версии вплоть до текущей 1.9.4 — и баг остался нетронутым во всех них. Поскольку XQUIC распространяется как открытый исходный код, любой сервер, который встроил её с настройками QPACK по умолчанию, уязвим. FoxIO прямо называет один конкретный продукт — Tengine, веб-сервер Alibaba на основе Nginx, который, по их данным, стоит перед облачной и CDN-инфраструктурой компании. В числе затронутых сайтов упомянуты Taobao и Alipay.
Чтобы понять суть бага, придётся немного углубиться в механику HTTP/3. Протокол использует QPACK для сжатия заголовков — чтобы не гонять по сети одно и то же значение user-agent в каждом запросе. Для этого QPACK держит общую динамическую таблицу, которую строит через отдельный канал управления — encoder stream. И именно клиент указывает серверу, как эту таблицу растить или уменьшать.
XQUIC хранит байты таблицы в кольцевом буфере — блоке фиксированной памяти, где данные при заполнении заворачиваются с конца на начало. Когда клиент просит таблицу увеличить, происходит три шага: выделяется буфер побольше, старые данные копируются в новый, а логика копирования разбита на четыре случая — в зависимости от того, где именно заворачиваются данные: в старом буфере, в новом, в обоих сразу или нигде. Баг живёт ровно в одном из этих четырёх случаев: там остаточные «хвостовые» байты меряются относительно ёмкости нового, большего буфера, вместо того чтобы мериться относительно ёмкости старого. Разница в размерах превращается в серьёзный перерасчёт не в ту сторону.
Фери привёл конкретный пример. Берём таблицу на 64 байта с курсором записи почти у самого конца, растим её до 65 байт — и XQUIC высчитывает, что нужно перенести 70 хвостовых байт. Реальное число — 6. Расхождение в разы.
Дальше это неверное, завышенное число попадает в операцию копирования памяти. Длина копирования вычисляется как разность между этим числом и меньшей величиной. Поскольку тип данных — беззнаковый size_t, вычитание уходит в underflow и оборачивается почти в максимальное значение переменной. В итоге операция копирования пытается пройти далеко за границы отведённой памяти.
Фери тестировал это на релизной сборке FoxIO под Ubuntu 26.04. Там сработала защита glibc — флаг _FORTIFY_SOURCE=2, который поймал некорректную длину и убил процесс, то есть просто произошёл крах программы. Но без этой защиты копирование пошло бы за пределы буфера уже не с падением, а с реальной записью данных из старого буфера за конец нового. Важная деталь: Фери показал именно крах сервера, но не проверял, можно ли эту порчу памяти развить дальше — например, в удалённое исполнение кода.
Ключевое здесь то, что ни одно из значений в атаке не нарушает правила протокола QPACK. Лимит XQUIC на динамическую таблицу по умолчанию — 16 килобайт. Вредоносная нагрузка запрашивает всего 64 байта, потом 65 — что укладывается в лимит с огромным запасом. Атакующему нужно лишь подвести таблицу к точной конфигурации заворота, при которой срабатывает бракованная ветка кода. Никаких битых пакетов, никакой аутентификации — только штатное поведение протокола, доведённое до нужного состояния.
Официального патча пока нет, поэтому речь идёт о двух обходных вариантах. Первый — выставить SETTINGS_QPACK_MAX_TABLE_CAPACITY в 0, что отключает динамическую таблицу QPACK целиком. Второй — банально отказаться от поддержки HTTP/3.
Похожие истории с падением серверов на HTTP/2 и HTTP/3 всплывали и раньше. За три недели до раскрытия XRING издание The Hacker News писало о CVE-2026-42530 — use-after-free в HTTP/3-модуле NGINX, достижимом удалённо и без авторизации через тот же самый encoder stream QPACK. В июне исследователь под псевдонимом Calif обнаружил атаку под названием HTTP/2 Bomb, эксплуатирующую HPACK — предшественника QPACK по части сжатия заголовков в HTTP/2; от неё досталось Nginx, Apache, IIS и Envoy. В феврале в HAProxy нашли две проблемы с крахами при обработке QUIC, одна из которых — целочисленный underflow при валидации токена, тот же класс бага, что и у XRING. Разница принципиальная: там атаке требовался испорченный пакет, здесь — нет.
Именно в этом The Hacker News видит главную особенность XRING: не поддельный трафик и не сложная цепочка эксплойтов, а простая арифметическая ошибка в сочетании с абсолютно легальными входными данными, которая укладывает сервер наповал. Издание направило вопросы обеим сторонам. У Alibaba спрашивают, готовится ли исправление и присвоение CVE, а также дошли ли до её команды безопасности пять попыток раскрытия, которые предприняла FoxIO. У самой FoxIO хотят узнать, фиксировались ли попытки эксплуатации в реальном мире и можно ли превратить эту порчу памяти в куче во что-то более серьёзное, чем банальный крах процесса.
На момент 10 июля CVE не присвоен, патча не существует, подтверждённых случаев эксплуатации в дикой природе, по данным FoxIO, не зафиксировано. Показан только крах сервера — не удалённое исполнение кода. История помечена как развивающаяся, и материал обещают обновить после ответов Alibaba и FoxIO.