Más rápido, más alto, más vulnerable: encuentran en el código de HTTP/3 la herramienta perfecta para lanzar DDoS gratis

Más rápido, más alto, más vulnerable: encuentran en el código de HTTP/3 la herramienta perfecta para lanzar DDoS gratis

Una solicitud especialmente diseñada puede saturar la CPU al 100% y bloquear la entrada de nuevas conexiones.

image

Errores en siete implementaciones populares de HTTP/3 permiten que un cliente remoto sobrecargue un servidor sin autenticación y sin un gran caudal de tráfico. Un especialista de FoxIO comprobó diez implementaciones y encontró que una pequeña petición comprimida en memoria puede expandirse decenas, cientos e incluso miles de veces. En pruebas aisladas, una sola conexión bastó para causar una denegación de servicio.

El problema está en QPACK, que comprime las cabeceras de HTTP/3. En lugar de enviar la misma cadena repetida, el cliente puede enviar un enlace corto a una entrada de la tabla, y el servidor luego reconstruye el valor completo. El ahorro funciona bien mientras el programa limite no solo los bytes recibidos, sino también el volumen de datos tras la descompresión. Varias bibliotecas controlaban la magnitud incorrecta, comprobaban el tamaño demasiado tarde o no establecían el límite necesario.

El investigador denominó la técnica Header Accordions. En una variante, el atacante rellena el bloque con multitud de cabeceras cortas: 1 MB de datos comprimidos se convertía aproximadamente en 160.000 campos. En otra variante, el cliente coloca primero en la tabla dinámica una entrada de alrededor de 4 KB y luego la referencia con enlaces de un byte. El servidor reconstruye la entrada completa cada vez y vuelve a consumir memoria. En algunas implementaciones, un byte transmitido provocaba la asignación de aproximadamente 4 KB, lo que supone una amplificación de unas 4.000 veces.

El escenario más grave lo reprodujo el investigador en Bun. Unos 5,8 MB de tráfico entrante fueron suficientes para agotar los 2 GB de memoria del contenedor. Un error separado en el código de gestión del búfer permitía lograr otro efecto: unos 516 KB de datos cargaban la CPU al 100%, tras lo cual el servidor dejaba de aceptar nuevas peticiones y no se recuperaba por sí mismo.

También se encontraron puntos vulnerables en quic-go, Cloudflare quiche, lsquic, aioquic con mitmproxy, la biblioteca h3 y Wireshark. Las causas variaron. quic-go limitaba el tamaño del bloque comprimido, pero no comprobaba el volumen final de las cabeceras. Cloudflare quiche calculaba mal el tamaño de los campos y podía reservar demasiada memoria de forma anticipada. h3 permitía acumular tantas cabeceras que la aplicación terminaba el procesamiento por error. En las pruebas, IIS, Envoy y el conjunto ngtcp2/nghttp3 resistieron las peticiones preparadas.

Algunos desarrolladores cerraron las vulnerabilidades antes de la publicación de los detalles. Las correcciones se incluyeron en quic-go 0.57.0, Cloudflare quiche 0.29.3, lsquic 4.9.0, Wireshark 4.6.2 y 4.4.12. Para los problemas en quic-go, quiche y Wireshark se registraron los CVE-2025-64702, CVE-2026-12523 y CVE-2025-13945.

En el momento de la publicación del análisis, Bun seguía siendo vulnerable, pero los desarrolladores más tarde publicaron la corrección en la versión 1.4.4. Ahora Bun limita el tamaño total de las cabeceras descomprimidas y el número de campos. Son vulnerables las versiones desde la 1.3.14 hasta la 1.4.3 inclusive, y el problema no afecta a HTTP/1.1 ni a HTTP/2.

Header Accordions es especialmente peligrosa por la diferencia en el coste entre ambas partes. El cliente envía enlaces compactos, mientras el servidor consume memoria y tiempo de CPU para reconstruir y almacenar un volumen de datos mucho mayor. Por eso, para el ataque no se necesita una botnet ni un caudal de cientos de gigabits por segundo: con una implementación vulnerable, un único cliente puede generar una carga desproporcionada respecto al volumen de tráfico enviado.