Una sola variable incorrecta en una línea en XQUIC, la biblioteca QUIC y HTTP/3 de Alibaba, permite que cualquier cliente remoto bloquee el servidor con una breve ráfaga de tráfico completamente legal. No hay ningún parche.
El investigador de FoxIO, Sébastien Féry, reveló la falla el 8 de julio y la apodó XRING. Dice que no necesita inicio de sesión ni paquetes con formato incorrecto: alrededor de 260 bytes de tráfico QPACK normal desactivan el proceso del servidor.
XQUIC es de código abierto, por lo que el riesgo no es solo de Alibaba: cualquier servidor que lo incorpore y sirva HTTP/3 con la configuración QPACK predeterminada está expuesto. Eso incluye Tengine, el servidor web basado en Nginx de Alibaba, que según FoxIO está al frente de la nube y CDN de la compañía en sitios como Taobao y Alipay.
Todas las versiones hasta la v1.9.4, la más reciente, se ven afectadas. No hay ninguna versión fija ni CVE a partir del 10 de julio. Hasta que se envíe una solución, los operadores pueden establecer SETTINGS_QPACK_MAX_TABLE_CAPACITY en 0, lo que desactiva la tabla dinámica de QPACK, o eliminar por completo el soporte HTTP/3.
El error radica en cómo HTTP/3 comprime los encabezados. Para evitar enviar el mismo encabezado (por ejemplo, agente de usuario) una y otra vez, HTTP/3 usa QPACK. Mantiene una tabla compartida que el cliente le indica al servidor que cree y cambie de tamaño a través de un canal de control dedicado, el flujo del codificador.
XQUIC almacena los bytes de esa tabla en un búfer de anillo, un bloque fijo de memoria donde los datos se ajustan desde el final hasta el inicio una vez que se llenan.
Cuando el cliente solicita hacer crecer la tabla, XQUIC asigna un búfer más grande y copia los datos antiguos. Esa copia tiene cuatro casos, dependiendo de si los datos se ajustan en el búfer antiguo, en el nuevo, en ambos o en ninguno. En uno de ellos, el código dimensiona los datos de cola sobrantes con respecto a la capacidad del nuevo búfer más grande en lugar de la del anterior. Se sobrecuenta mucho.
Haga crecer una tabla de 64 bytes con el cursor de escritura cerca del final y cambie el tamaño a 65, y XQUIC decide que hay 70 bytes finales para mover cuando en realidad hay 6.
Ese número incorrecto fluye hacia una copia de memoria. La longitud de la copia proviene de restar el recuento excesivo de un valor menor. Debido a que esa longitud es un size_t sin firmar, se desborda y se ajusta a un número casi máximo, y la copia se ejecuta hasta el final de la memoria.
En la versión de lanzamiento de FoxIO en Ubuntu 26.04, _FORTIFY_SOURCE=2 de glibc detectó la longitud incorrecta y finalizó el proceso. Sin esa verificación, la copia escribe fuera de los límites, desde el búfer antiguo más allá del final del nuevo. Féry mostró un fracaso, pero no probó si esa corrupción podría explotarse más.
Ninguno de los valores del ataque infringe las reglas de QPACK. XQUIC anuncia un límite de tabla dinámica de 16 KiB de forma predeterminada; la carga útil solicita 64 bytes, luego 65. El cliente solo tiene que conducir la tabla al diseño ajustado exacto que llega a la rama defectuosa. FoxIO dice que el error ha estado en XQUIC desde su primer lanzamiento público en enero de 2022, y una prueba de concepto es pública.
XRING es el último de una serie de fallos remotos en pilas HTTP/2 y HTTP/3. Tres semanas antes, THN informó un uso después de la liberación en el módulo HTTP/3 de NGINX (CVE-2026-42530) al que un cliente remoto y no autenticado podría acceder a través del mismo flujo de codificador QPACK, abusos XRING, una clase de error diferente en la misma superficie de ataque.
En junio, la bomba HTTP/2 de Calif provocó una denegación remota de servicio contra Nginx, Apache, IIS y Envoy al abusar de HPACK, la compresión de encabezados de HTTP/2 y el predecesor de QPACK.
En febrero, HAProxy solucionó dos fallos de QUIC, uno de ellos por un desbordamiento insuficiente de enteros durante la validación del token, el mismo tipo de error detrás de XRING, aunque necesitaba un paquete con formato incorrecto donde XRING no necesita ninguno. Esa diferencia es el punto: entrada legal, un error aritmético, un servidor muerto.
FoxIO demostró una falla, no una ejecución de código, y no informó ninguna explotación en la naturaleza. Dice que envió un correo electrónico a Alibaba el 7 de abril a través de la política de seguridad del proyecto, que promete una respuesta dentro de tres días hábiles, y luego hizo un seguimiento cuatro veces más hasta el 9 de mayo sin respuesta antes de hacerse público.
Hacker News ha preguntado a Alibaba si habrá una solución y un CVE, y si los cinco intentos de divulgación de FoxIO llegaron a su equipo de seguridad. Le ha preguntado a FoxIO si la falla ha sido explotada en la naturaleza y si la escritura en el montón subyacente puede superar una falla. La historia se actualizará con cualquier respuesta.
