Една сгрешена променлива на един ред в XQUIC, библиотеката за QUIC и HTTP/3 на Alibaba, позволява на всеки отдалечен клиент да срине сървъра с кратък импулс от напълно легитимен трафик. Към момента няма налична корекция (пач).
Изследователят Себастиан Фери от FoxIO разкри уязвимостта на 8 юли и я нарече XRING. Той споделя, че за атаката не е необходимо влизане в системата или неправилно форматирани пакети: около 260 байта обикновен QPACK трафик са достатъчни да спрат сървърния процес.
XQUIC е с отворен код, така че рискът не е само за Alibaba: всеки сървър, който го интегрира и обслужва HTTP/3 с настройките по подразбиране за QPACK, е изложен на опасност. Това включва Tengine, уеб сървъра на Alibaba, базиран на Nginx, който според FoxIO обслужва облака и CDN мрежата на компанията за сайтове като Taobao и Alipay.
Засегнати са всички версии до последната v1.9.4. Към 10 юли няма коригирана версия нито заведен CVE код. Докато не бъде пусната корекция, администраторите могат да зададат SETTINGS_QPACK_MAX_TABLE_CAPACITY на 0, което изключва динамичната таблица на QPACK, или напълно да спрат поддръжката на HTTP/3.
Проблемът е в начина, по който HTTP/3 компресира хедърите. За да избегне повторно изпращане на едни и същи хедъри, HTTP/3 използва QPACK. Той поддържа споделена таблица, която клиентът указва на сървъра да изгради и преоразмери чрез предназначен за това контролен канал (encoder stream).
XQUIC съхранява байтовете на тази таблица в ring buffer (цикличен буфер) – фиксиран блок памет, в който данните се прехвърлят от края обратно в началото, когато се запълни.
Когато клиентът поиска уголемяване на таблицата, XQUIC заделя по-голям буфер и копира старите данни в него. Това копиране има четири сценария в зависимост от това дали данните се прехвърлят в стария буфер, в новия, в двата или в нито един. В един от тези случаи кодът изчислява размера на оставащите данни в края спрямо капацитета на новия, по-голям буфер, вместо спрямо стария. Това води до сериозно надвишаване на реалния размер.
При уголемяване на таблица от 64 байта с показалец за запис близо до края и преоразмеряване до 65 байта, XQUIC решава, че има 70 байта за преместване, когато в действителност те са само 6.
Това грешно число се предава на функция за копиране на памет. Дължината на копирането се получава чрез изваждане на прекомерно пресметнатата стойност от по-малка стойност. Тъй като тази дължина е от тип без знак size_t, се получава отрицателно препълване (underflow) и стойността става близка до максимално възможната, в резултат на което копирането излиза извън границите на заделената памет.
В тестовата компилация на FoxIO върху Ubuntu 26.04 функцията _FORTIFY_SOURCE=2 на glibc засича грешната дължина и прекратява процеса. Без тази защита се стига до излизане извън границите на буфера (out-of-bounds write). Фери демонстрира срив на системата, но не е тествал дали тази повреда на паметта може да се използва за изпълнение на произволен код.
Никакви стойности в атаката не нарушават правилата на QPACK. По подразбиране XQUIC декларира лимит на динамичната таблица от 16 KiB; зловредният товар изисква 64 байта, а след това 65. Клиентът трябва само да приведе таблицата в точната циклично затворена подредба, която задейства дефектния клон в кода. FoxIO твърди, че грешката съществува в XQUIC от първата му публична версия през януари 2022 г., а концептуалният код за атака (PoC) вече е публичен.
XRING е поредният случай от поредица отдалечени сривове в HTTP/2 и HTTP/3 стековете. Хакери наскоро откриха и уязвимост от тип use-after-free в HTTP/3 модула на NGINX (CVE-2026-42530), която отдалечен неоторизиран клиент може да достигне по същия начин.
През юни атаката "HTTP/2 Bomb" причини отдалечен отказ от услуга (DoS) срещу Nginx, Apache, IIS и Envoy чрез злоупотреба с HPACK (предшественика на QPACK). През февруари HAProxy коригира два срива на QUIC, единият от които беше свързан с аритметично препълване на цяло число при проверка на токени – същият тип грешка, който стои зад XRING.
FoxIO демонстрира срив на сървъра, а не изпълнение на зловреден код, и няма данни за реално използване на уязвимостта за атаки. Компанията се е свързала с Alibaba още на 7 април, но след няколко последващи опита за контакт без отговор е решила да публикува информацията.