У бібліотеці XQUIC — відкритій реалізації протоколів QUIC і HTTP/3 від Alibaba — виявлено вразливість, що дозволяє віддаленому неавтентифікованому клієнту аварійно завершити серверний процес, надіславши приблизно 260 байт повністю легітимного QPACK-трафіку. Вразливість, що отримала назву XRING, зачіпає всі випуски XQUIC включно з актуальною версією 1.9.4. Станом на 10 липня патч відсутній, CVE не присвоєно. Операторам серверів на базі XQUIC рекомендується негайно вимкнути динамічну таблицю QPACK, встановивши параметр SETTINGS_QPACK_MAX_TABLE_CAPACITY у 0, або повністю деактивувати підтримку HTTP/3.
Механізм вразливості
Дослідник Себастьєн Фері з FoxIO публічно розкрив вразливість 8 липня. Корінь проблеми — в логіці розширення кільцевого буфера, який XQUIC використовує для зберігання динамічної таблиці QPACK. Код розташований у файлі xqc_ring_mem.c.
HTTP/3 застосовує QPACK для стиснення повторюваних заголовків. Клієнт через виділений керівний канал (encoder stream) інструктує сервер нарощувати й змінювати розмір спільної таблиці. Коли клієнт запитує збільшення таблиці, XQUIC виділяє новий, більший буфер і копіює до нього дані зі старого. Процес копіювання обробляє чотири сценарії залежно від того, чи є дані в старому буфері «обгорнутими», у новому, в обох або в жодному.
В одному з цих сценаріїв код помилково обчислює розмір «хвостових» даних, використовуючи місткість нового буфера замість старого. Це призводить до грубого завищення довжини блоку, що копіюється. За даними дослідника, під час розширення 64-байтової таблиці до 65 байт із курсором запису поблизу кінця буфера XQUIC обчислює 70 байт хвостових даних замість реальних 6.
Завищене значення далі використовується в арифметиці довжини для виклику копіювання пам’яті. Оскільки довжина зберігається в беззнаковому типі size_t, віднімання завищеного числа від меншого значення призводить до цілочисельного переповнення знизу — довжина «загортається» до майже максимального значення. Результат — спроба копіювання далеко за межі виділеної пам’яті.
У тестовому середовищі FoxIO (Ubuntu, збірка з _FORTIFY_SOURCE=2) захисний механізм glibc виявляв некоректну довжину й примусово завершував процес. Без цієї перевірки копіювання записує дані за межі нового буфера. Дослідник продемонстрував аварійне завершення, але не перевіряв, чи можлива експлуатація для виконання довільного коду.
Що робить XRING особливо небезпечною
Ключова особливість цієї вразливості — атака не потребує ані автентифікації, ані надсилання спотворених пакетів. Усі значення, використані в атаці, відповідають специфікації QPACK. XQUIC за замовчуванням оголошує ліміт динамічної таблиці в 16 КіБ; експлойт послідовно запитує 64 і 65 байт — обидва значення цілком легітимні. Клієнту достатньо привести таблицю до певного стану «обгорнутості», щоб активувати дефектну гілку коду.
За даними FoxIO, помилка присутня в XQUIC із моменту першого публічного випуску в січні 2022 року. Публічний PoC-експлойт доступний на GitHub. Експлуатації у реальних атаках на момент розкриття не зафіксовано.
Уражені продукти та масштаб впливу
XQUIC — бібліотека з відкритим вихідним кодом, і ризик не обмежується інфраструктурою Alibaba. За даними дослідників, вразливою є будь-яка серверна інстанція, що використовує XQUIC для обслуговування HTTP/3 з налаштуваннями QPACK за замовчуванням. Серед уражених продуктів:
- Alibaba XQUIC — усі версії до v1.9.4 включно
- Tengine — веб-сервер Alibaba на базі Nginx, який, за твердженням FoxIO, обслуговує хмарну інфраструктуру та CDN компанії
Варто зазначити, що твердження щодо масштабу впливу на інфраструктуру Alibaba ґрунтуються виключно на даних дослідника — офіційного підтвердження від вендора отримано не було.
Контекст: серія вразливостей у HTTP/2 та HTTP/3
XRING вписується в тривожну тенденцію виявлення вразливостей віддаленої відмови в обслуговуванні у стеках HTTP/2 та HTTP/3. Трьома тижнями раніше було розкрито вразливість типу use-after-free в модулі HTTP/3 NGINX (CVE-2026-42530), яку експлуатують через той самий QPACK encoder stream — інший клас помилки, але ідентична поверхня атаки. У лютому HAProxy виправила два аварійні завершення в QUIC, одне з яких також було спричинене цілочисельним переповненням знизу — тим самим типом помилки, що й у XRING, але для його експлуатації був потрібен спотворений пакет.
Принципова відмінність XRING: для атаки достатньо повністю легітимного вводу. Одна арифметична помилка — і сервер припиняє роботу.
Рекомендації щодо митигації
Оскільки офіційний патч відсутній, операторам серверів на базі XQUIC необхідно застосувати обхідні заходи:
- Вимкнути динамічну таблицю QPACK — встановити параметр
SETTINGS_QPACK_MAX_TABLE_CAPACITYу значення 0. Це усуває вектор атаки, але збільшує обсяг передаваних заголовків. - Повністю вимкнути підтримку HTTP/3 — радикальний захід, але такий, що гарантовано унеможливлює експлуатацію цієї вразливості.
- Відстежувати оновлення XQUIC — перевіряти репозиторій проєкту на предмет виходу виправленої версії.
- Переконатися в наявності захисту
_FORTIFY_SOURCE— у збірках із цією опцією glibc перехоплює некоректне копіювання й завершує процес, запобігаючи потенційному запису за межі буфера. Це не усуває відмову в обслуговуванні, але знижує ризик глибшої експлуатації.
Хронологія розкриття
За заявою FoxIO, компанія надіслала сповіщення Alibaba 7 квітня через механізм, описаний у політиці безпеки проєкту (яка обіцяє відповідь протягом трьох робочих днів), а потім надіслала ще чотири звернення аж до 9 травня — жодне з них не отримало відповіді. Після цього дослідник ухвалив рішення про публічне розкриття. Підтвердження цієї хронології з боку Alibaba немає.
Операторам серверів, які використовують XQUIC або Tengine з підтримкою HTTP/3, слід негайно застосувати описані обхідні заходи — щонайменше встановити SETTINGS_QPACK_MAX_TABLE_CAPACITY=0. За наявності публічного PoC і відсутності патча вікно для атаки відкрите, а вартість експлуатації для зловмисника мінімальна: 260 байт трафіку, який не потребує ані автентифікації, ані порушення протоколу.
