Около 260 байт легитимного QPACK-трафика достаточно, чтобы удалённо обрушить HTTP/3-сервер на базе XQUIC. Для операторов, которые используют эту библиотеку в продакшене, уязвимость XRING выглядит неприятно именно своей простотой: без логина, без битых пакетов, без экзотики, только корректный сетевой обмен, который завершает процесс сервера.
Проблему 8 июля раскрыл исследователь FoxIO Себастьien Féry, а по данным The Hacker News, уязвимы все релизы XQUIC вплоть до версии 1.9.4, то есть и актуальный на 10 июля выпуск тоже. Исправления пока нет, CVE тоже не присвоен. Для экосистемы это важная деталь: XQUIC — не внутренний компонент одной компании, а open-source библиотека Alibaba для QUIC и HTTP/3, поэтому риск касается не только самой Alibaba, но и всех, кто встроил её в собственные HTTP/3-стэки.
Технически ошибка почти анекдотическая: одна неверно выбранная переменная в строке кода. Но последствия вполне производственные. Баг живёт в механизме QPACK — это сжатие HTTP/3-заголовков, которое позволяет не пересылать одни и те же header'ы заново. XQUIC хранит динамическую таблицу QPACK в кольцевом буфере. Когда клиент просит увеличить таблицу, библиотека создаёт новый буфер побольше и переносит в него старые данные. В одном из четырёх сценариев копирования код считает хвост данных не по ёмкости старого буфера, а по размеру нового. Из-за этого при увеличении таблицы, например, с 64 до 65 байт библиотека может решить, что переносить нужно 70 байт, хотя реально их шесть.
Дальше срабатывает классическая арифметическая ловушка. Из-за неправильного подсчёта длина копирования получается через вычитание, уходит в underflow и для беззнакового size_t превращается почти в максимальное значение. В сборке FoxIO на Ubuntu 26.04 защитный механизм glibc с _FORTIFY_SOURCE=2 распознал некорректную длину и просто убил процесс. Это, впрочем, не делает ситуацию безобидной: без такой проверки копирование уходит за границы памяти, то есть речь уже о внештатной записи в heap. Féry показал именно падение сервера и не заявлял, что довёл кейс до удалённого исполнения кода, но даже чистый отказ в обслуживании для HTTP/3-фронтенда — вполне прикладная проблема.
Ключевой момент в том, что атака не нарушает правил протокола. XQUIC по умолчанию рекламирует лимит динамической таблицы в 16 КиБ, а для срабатывания достаточно последовательно запросить 64 байта, затем 65 байт и довести буфер до нужного состояния с заворотом данных. Именно это делает уязвимость XRING неприятнее многих похожих багов: сетевые фильтры и аномалия-детекторы обычно охотнее цепляются за мусорный трафик или malformed packets, а здесь достаточно короткой серии обычных QPACK-команд. То есть эксплуатация выглядит как нормальный диалог клиента с HTTP/3-сервером, только с очень плохим финалом для сервера.
Радиус поражения тоже нельзя назвать узким. FoxIO отдельно указывает на Tengine — nginx-подобный веб-сервер Alibaba, который использует XQUIC. Исследователи связывают его в том числе с облачной и CDN-инфраструктурой компании на сайтах вроде Taobao и Alipay. Но новость важна не только для крупных китайских платформ. Любой вендор, интегратор или внутренняя платформа, которые взяли XQUIC как готовую реализацию HTTP/3 с настройками QPACK по умолчанию, получают тот же риск: удалённый и неаутентифицированный DoS по вполне легальному протокольному сценарию. Временные обходные меры есть две: выставить SETTINGS_QPACK_MAX_TABLE_CAPACITY в 0 и тем самым отключить динамическую таблицу QPACK либо полностью выключить HTTP/3.
На этом фоне XRING хорошо ложится в более широкий тренд 2026 года: атаки и аварии всё чаще приходят не из редких RCE-цепочек, а из ошибок в базовой сетевой математике вокруг HTTP/2 и HTTP/3. The Hacker News напоминает, что всего за три недели до этого разбиралась use-after-free уязвимость в HTTP/3-модуле NGINX с идентификатором CVE-2026-42530, которая тоже достигалась через QPACK encoder stream. В июне исследователи описали HTTP/2 Bomb против Nginx, Apache, IIS и Envoy через HPACK, предшественника QPACK. В феврале HAProxy уже закрывал два падения в QUIC, одно из них тоже было связано с integer underflow. Разница в деталях, но общий вывод неприятный: компрессия заголовков и служебные потоки HTTP нового поколения становятся всё более привлекательной поверхностью атаки.
Есть и организационный сюжет, который для open-source не менее показателен, чем сам баг. FoxIO утверждает, что впервые написала Alibaba 7 апреля по каналу, указанному в security policy проекта, где обещан ответ в течение трёх рабочих дней. Затем последовали ещё четыре письма до 9 мая, но ответа, по словам исследователей, не было, после чего раскрытие стало публичным. Если эта хронология точна, проблема уже выходит за рамки одной неудачной строчки в коде. Для бизнеса это вопрос зрелости процессов безопасности вокруг open-source компонентов: скорость патча часто зависит не от того, насколько сложен баг, а от того, дошло ли письмо до нужной команды и есть ли у проекта привычка реагировать раньше, чем PoC оказывается в паблике.
История с уязвимостью XRING пока выглядит как чистый DoS без подтверждённой эксплуатации в бою, но именно такие баги обычно быстро превращаются в чек-лист для SRE и AppSec-команд. QUIC и HTTP/3 продолжают набирать долю, а значит, каждый просчёт в QPACK и соседних механизмах будет всё реже оставаться лабораторным кейсом и всё чаще становиться операционной проблемой для реальных сервисов. Проверить детали раскрытия можно в публикации .