Detalles de la vulnerabilidad
Un error en una sola línea de 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 existe parche. El investigador de FoxIO, Sébastien Féry, reveló la falla el 8 de julio y la apodó XRING. Afirma que no requiere inicio de sesión ni paquetes malformados: unos 260 bytes de tráfico QPACK ordinario bastan para derribar el proceso del servidor.
XQUIC es de código abierto, por lo que el riesgo no es solo de Alibaba: cualquier servidor que lo integre y sirva HTTP/3 con la configuración QPACK predeterminada está expuesto. Esto incluye Tengine, el servidor web basado en Nginx de Alibaba, que FoxIO dice que respalda la nube y CDN de la empresa en sitios como Taobao y Alipay.
Todas las versiones hasta la 1.9.4, la más reciente, están afectadas. No hay una versión corregida ni CVE al 10 de julio. Hasta que llegue 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.
Origen del error
El error reside en cómo HTTP/3 comprime las cabeceras. Para evitar enviar la misma cabecera (por ejemplo, user-agent) una y otra vez, HTTP/3 usa QPACK. Mantiene una tabla compartida que el cliente indica al servidor que construya y redimensione a través de un canal de control dedicado, el flujo de codificador.
XQUIC almacena los bytes de esa tabla en un búfer circular, un bloque de memoria fijo donde los datos se envuelven desde el final hasta el inicio una vez que se llena. Cuando el cliente solicita agrandar 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 envuelven en el búfer antiguo, el nuevo, ambos o ninguno. En uno de ellos, el código dimensiona los datos sobrantes contra la capacidad del búfer nuevo y más grande en lugar de la del antiguo. La sobreestimación es grave.
Si se agranda una tabla de 64 bytes con el cursor de escritura cerca del final, y se redimensiona a 65, XQUIC decide que hay 70 bytes sobrantes que mover cuando en realidad hay 6. Ese número incorrecto fluye a una copia de memoria. La longitud de copia proviene de restar la sobreestimación de un valor más pequeño. Debido a que esa longitud es un size_t sin signo, se desborda y se envuelve a un número casi máximo, y la copia se sale de la memoria.
En la compilación de lanzamiento de FoxIO en Ubuntu 26.04, _FORTIFY_SOURCE=2 de glibc detectó la longitud incorrecta y eliminó 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 bloqueo pero no probó si esa corrupción podría explotarse más.
Contexto y estado
Ninguno de los valores del ataque viola las reglas de QPACK. XQUIC anuncia un límite de tabla dinámica de 16 KiB por defecto; la carga útil solicita 64 bytes, luego 65. El cliente solo tiene que llevar la tabla a la disposición exacta que activa 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 bloqueos remotos en pilas HTTP/2 y HTTP/3. Tres semanas antes, THN informó de un use-after-free en el módulo HTTP/3 de NGINX (CVE-2026-42530) que un cliente remoto no autenticado podía alcanzar a través del mismo flujo de codificador QPACK que abusa XRING, una clase de error diferente en la misma superficie de ataque.
En junio, la Bomba HTTP/2 de Calif causó denegación de servicio remota contra Nginx, Apache, IIS y Envoy al abusar de HPACK, la compresión de cabeceras de HTTP/2, y predecesora de QPACK. En febrero, HAProxy parcheó dos bloqueos de QUIC, uno un desbordamiento de enteros durante la validación de tokens, el mismo tipo de error detrás de XRING, aunque necesitaba un paquete malformado donde XRING no necesita ninguno. Esa diferencia es el punto: entrada legal, un desliz aritmético, un servidor caído.
FoxIO demostró un bloqueo, no ejecución de código, y no reportó explotación en la naturaleza. Afirma 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 en tres días hábiles, y luego hizo un seguimiento cuatro veces más hasta el 9 de mayo sin respuesta antes de hacerlo público.
The Hacker News ha preguntado a Alibaba si se lanzará un parche y un CVE, y si los cinco intentos de divulgación de FoxIO llegaron a su equipo de seguridad. Ha preguntado a FoxIO si la falla ha sido explotada en la naturaleza y si la escritura en el montón subyacente puede llevarse más allá de un bloqueo. La historia se actualizará con cualquier respuesta.
Deja una respuesta