Vulnerabilidad XRING en XQUIC permite DoS sin autenticación vía QPACK

En la biblioteca XQUIC, una implementación abierta de los protocolos QUIC y HTTP/3 de Alibaba, se ha descubierto una vulnerabilidad que permite a un cliente remoto no autenticado terminar de forma abrupta el proceso del servidor enviando aproximadamente 260 bytes de tráfico QPACK totalmente legítimo. La vulnerabilidad, denominada XRING, afecta a todas las versiones de XQUIC hasta la versión actual 1.9.4 incluida. A fecha de 10 de julio no existe parche ni se le ha asignado un identificador CVE. Se recomienda a los operadores de servidores basados en XQUIC desactivar de inmediato la tabla dinámica de QPACK estableciendo el parámetro SETTINGS_QPACK_MAX_TABLE_CAPACITY en 0, o bien desactivar por completo el soporte de HTTP/3.

Mecanismo de la vulnerabilidad

El investigador Sébastien Ferré, de FoxIO, divulgó públicamente la vulnerabilidad el 8 de julio. La raíz del problema está en la lógica de ampliación del búfer circular que XQUIC utiliza para almacenar la tabla dinámica de QPACK. El código se encuentra en el archivo xqc_ring_mem.c.

HTTP/3 emplea QPACK para comprimir encabezados repetitivos. A través de un canal de control dedicado (encoder stream), el cliente instruye al servidor para ampliar y redimensionar la tabla compartida. Cuando el cliente solicita un aumento de la tabla, XQUIC reserva un nuevo búfer de mayor tamaño y copia en él los datos del anterior. El proceso de copia contempla cuatro escenarios en función de si los datos están «envueltos» en el búfer antiguo, en el nuevo, en ambos o en ninguno.

En uno de estos escenarios, el código calcula por error el tamaño de los datos de «cola» usando la capacidad del búfer nuevo en lugar del antiguo. Esto provoca una sobreestimación considerable de la longitud del bloque que se va a copiar. Según el investigador, al ampliar una tabla de 64 bytes a 65 bytes con el cursor de escritura cerca del final del búfer, XQUIC calcula 70 bytes de datos de cola en lugar de los 6 reales.

El valor inflado se utiliza posteriormente en las operaciones aritméticas sobre la longitud para la llamada de copia de memoria. Dado que la longitud se almacena en un tipo sin signo size_t, restar una cantidad inflada de un valor menor provoca un desbordamiento entero por debajo (integer underflow): la longitud «se envuelve» hasta un valor cercano al máximo. El resultado es un intento de copiar muy por encima de los límites de la memoria reservada.

En el entorno de pruebas de FoxIO (Ubuntu, compilación con _FORTIFY_SOURCE=2), el mecanismo de protección de glibc detectaba la longitud incorrecta y forzaba la finalización del proceso. Sin esa comprobación, la copia escribe datos más allá de los límites del nuevo búfer. El investigador demostró el cierre abrupto del proceso, pero no verificó si es posible explotar la vulnerabilidad para ejecutar código arbitrario.

Qué hace especialmente peligrosa a XRING

La característica clave de esta vulnerabilidad es que el ataque no requiere autenticación ni el envío de paquetes malformados. Todos los valores utilizados en el ataque cumplen la especificación de QPACK. XQUIC, de forma predeterminada, declara un límite de 16 KiB para la tabla dinámica; el exploit solicita sucesivamente 64 y 65 bytes, valores ambos completamente legítimos. Al cliente le basta con llevar la tabla a un determinado estado de «envoltura» para activar la rama defectuosa del código.

Según FoxIO, el error está presente en XQUIC desde la primera versión pública de enero de 2022. En GitHub está disponible un exploit PoC público. En el momento de la divulgación no se habían registrado casos de explotación en ataques reales.

Productos afectados y alcance del impacto

XQUIC es una biblioteca de código abierto, y el riesgo no se limita a la infraestructura de Alibaba. De acuerdo con los investigadores, cualquier servidor que utilice XQUIC para atender HTTP/3 con la configuración predeterminada de QPACK es vulnerable. Entre los productos afectados figuran:

• Alibaba XQUIC: todas las versiones hasta la v1.9.4 inclusive
• Tengine: servidor web de Alibaba basado en Nginx que, según FoxIO, sirve a la infraestructura en la nube y a la CDN de la compañía

Conviene señalar que las afirmaciones sobre el alcance del impacto en la infraestructura de Alibaba se basan exclusivamente en los datos del investigador; no se ha recibido confirmación oficial por parte del proveedor.

Contexto: serie de vulnerabilidades en HTTP/2 y HTTP/3

XRING encaja en una tendencia preocupante de hallazgo de vulnerabilidades de denegación de servicio remota en los stacks de HTTP/2 y HTTP/3. Tres semanas antes se reveló una vulnerabilidad de tipo use-after-free en el módulo HTTP/3 de NGINX (CVE-2026-42530), explotable a través del mismo encoder stream de QPACK — otro tipo de error, pero con una superficie de ataque idéntica. En febrero, HAProxy corrigió dos cierres abruptos en QUIC, uno de los cuales también estaba provocado por un desbordamiento entero por debajo: el mismo tipo de error que en XRING, aunque en ese caso requería un paquete malformado para su explotación.

La diferencia fundamental de XRING es que para el ataque basta con una entrada completamente legítima. Un solo error aritmético y el servidor deja de funcionar.

Recomendaciones de mitigación

Dado que no existe un parche oficial, los operadores de servidores basados en XQUIC deben aplicar medidas de contención:

1. Desactivar la tabla dinámica de QPACK: establecer el parámetro SETTINGS_QPACK_MAX_TABLE_CAPACITY en el valor 0. Esto elimina el vector de ataque, pero aumenta el volumen de encabezados transmitidos.
2. Desactivar por completo el soporte de HTTP/3: una medida radical, pero que excluye de forma garantizada la explotación de esta vulnerabilidad.
3. Vigilar las actualizaciones de XQUIC: comprobar el repositorio del proyecto para detectar la publicación de una versión corregida.
4. Verificar la presencia de la protección _FORTIFY_SOURCE: en compilaciones con esta opción, glibc intercepta la copia incorrecta y finaliza el proceso, evitando una posible escritura fuera de los límites del búfer. Esto no elimina la denegación de servicio, pero reduce el riesgo de una explotación más profunda.

Cronología de la divulgación

Según FoxIO, la empresa envió una notificación a Alibaba el 7 de abril a través del mecanismo descrito en la política de seguridad del proyecto (que promete respuesta en un plazo de tres días laborables) y, posteriormente, remitió otras cuatro comunicaciones hasta el 9 de mayo, sin recibir respuesta a ninguna de ellas. Tras ello, el investigador decidió proceder a la divulgación pública. No existe confirmación por parte de Alibaba de esta cronología.

Los operadores de servidores que utilicen XQUIC o Tengine con soporte de HTTP/3 deben aplicar de inmediato las medidas de contención descritas —como mínimo, establecer SETTINGS_QPACK_MAX_TABLE_CAPACITY=0. Con un PoC público disponible y sin parche, la ventana de ataque está abierta, y el coste de explotación para un atacante es mínimo: 260 bytes de tráfico que no requieren ni autenticación ni violar el protocolo.