Investigadores de seguridad han revelado dos ataques de denegación de servicio (DoS) que aprovechan cómo las principales redes de entrega de contenido (CDN) convierten el tráfico HTTP/3 del cliente en solicitudes HTTP/1.1 hacia los sitios web que protegen, amplificando un flujo de solicitudes de bajo ancho de banda hasta 350 veces contra el servidor de origen. Los ataques, denominados colectivamente 'CDN Tsunami', fueron evaluados contra Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly y Tencent.
Los seis proveedores resultaron susceptibles a la variante de amplificación de ancho de banda y cinco a la de conexión; Cloudflare no se vio afectado por esta última porque almacena en búfer la solicitud completa antes de abrir una conexión al origen. El ataque requiere que el sitio web esté alojado en uno de estos seis proveedores, con HTTP/3 activo en el borde, sin necesidad de cambiar la configuración del sitio. El documento señala que HTTP/3 está habilitado por defecto en Cloudflare y CloudFront, aunque la documentación de Cloudflare describe HTTP/3 como disponible en todos los planes y proporciona pasos para activarlo, y AWS documenta http2 como la versión HTTP predeterminada para nuevas distribuciones de CloudFront.
El factor de amplificación de 350x se aplica solo a Alibaba, Baidu y Tencent, que soportan la tabla dinámica QPACK; se midió con aproximadamente 64 flujos concurrentes. En el resto, el máximo varió desde 36.41x hasta 51.2x. No se han asignado identificadores CVE ni se ha reportado explotación en la naturaleza. Mientras que Baidu y Tencent confirmaron los informes y desplegaron las correcciones propuestas, los investigadores señalan que todas las mitigaciones propuestas se aplican en la CDN, no en el sitio de origen.
Técnicas de ataque: HBA y HCA
Las dos técnicas se denominan Amplificación de Ancho de Banda HTTP/3 (HBA) y Amplificación de Conexión HTTP/3 (HCA). Ambas se basan en la misma brecha de implementación: la CDN habla HTTP/3 con el navegador pero solo HTTP/1.1 con el sitio web detrás, un desajuste que existe porque 'las CDN no soportan HTTP/3 de extremo a extremo'.
HBA aprovecha QPACK, el formato de compresión de cabeceras introducido con HTTP/3. Como HTTP/1.1 no tiene un mecanismo equivalente, la CDN debe expandir cada pequeño valor de índice que recibe a una cabecera completa antes de reenviar la solicitud. Así, una solicitud que al atacante le cuesta unos pocos bytes en la red, al origen le cuesta el tamaño descomprimido. El ancho de banda del atacante se mantuvo por debajo de 500 Kbps contra las tres CDN que soportan la tabla dinámica, y por debajo de 5 Mbps contra el resto, mientras que el consumo en el origen superó los 100 Mbps.
La variante de tabla dinámica requiere que el atacante envíe primero una solicitud HTTP/3 con una cabecera grande, que la CDN inserta en la tabla, y luego referencie esa entrada repetidamente con pequeños valores de índice. Solo Alibaba, Baidu y Tencent la soportan, cada uno con una tabla de 4KB y un tamaño máximo de entrada de 3,072 bytes. Los factores máximos de amplificación de ancho de banda medidos con la tabla estática QPACK son: Baidu 66.06x, Alibaba 65.8x, Tencent 54.08x, Amazon CloudFront 51.2x, Cloudflare 48.27x y Fastly 36.41x.
HCA ataca la capacidad de conexión en lugar del ancho de banda. Cinco de las seis CDN abren una conexión HTTP/1.1 al origen tan pronto como reciben el marco HEADERS de HTTP/3, antes de que llegue el cuerpo de la solicitud. La multiplexación HTTP/3 permite que una sola conexión de cliente transporte múltiples flujos, cada uno disparando su propia conexión TCP al backend. Al enviar marcos DATA a una velocidad muy baja, se mantienen abiertas esas conexiones, y la CDN sigue tratando la solicitud como incompleta.
En una prueba contra un servidor Apache con tiempo de espera de 300 segundos y límite de 256 conexiones, cuatro conexiones HTTP/3, cada una multiplexando 96 flujos, forzaron 384 conexiones de backend. Fastly requirió 48 conexiones de 8 flujos porque limita las conexiones de backend a 10 por conexión HTTP/3. Los tiempos de respuesta para un cliente benigno alcanzaron 60 segundos en Alibaba y hasta 90 segundos en Baidu y CloudFront, ambos devolviendo HTTP 504 Gateway Timeout; Fastly aumentó a 15 segundos y devolvió HTTP 503 Service Unavailable. Tencent cerró la conexión del cliente aproximadamente 10 segundos después de recibir una solicitud de prueba y no devolvió respuesta.
Alcance y exposición
Los experimentos se limitaron a un origen de 100 Mbps y un atacante de 30 Mbps, y no se reportaron pruebas por encima de esas cifras. El documento afirma que los ataques escalan a servidores de mayor capacidad, aunque no lo prueba. El factor de amplificación alcanza su punto máximo cerca de 64 flujos concurrentes y luego declina, atribuido a la sobrecarga de CPU en el borde de la CDN, aunque no se presentan mediciones.
Para evaluar la exposición, el equipo enumeró subdominios bajo la lista Tranco Top 1M, rastreó sus registros CNAME y NS, los comparó con sufijos conocidos asignados por CDN, y probó cada uno con aioquic. Esto produjo 151,685 subdominios alojados en los seis proveedores; de ellos, 42,330 respondieron a una solicitud HTTP/3 y se etiquetaron como potencialmente vulnerables, con los recuentos más altos en CloudFront (17,431), Cloudflare (12,371) y Fastly (11,606). La prueba solo establece que el borde de la CDN responde a HTTP/3, y no se atacó ningún servidor de origen fuera del entorno de prueba de los investigadores.
Los resultados se comparan con CDN Judo, un estudio de 2020 sobre la conversión equivalente de HTTP/2 a HTTP/1.1 en CDN, que reportó factores de aproximadamente 44x con la tabla estática y 166x con la dinámica. Las mitigaciones propuestas a los proveedores se aplican en la CDN e incluyen: limitar el tamaño de las entradas de la tabla dinámica QPACK (sugerido 512 bytes), limitar las referencias por entrada (sugerido 10), fijar un tamaño máximo de solicitud HTTP/1.1 descomprimida (sugerido 64KB), almacenar en búfer la solicitud HTTP/3 completa antes de abrir la conexión al origen, limitar las conexiones CDN-origen por conexión de cliente HTTP/3, y tiempos de espera independientes (sugerido 30 segundos).
Tencent desplegó mitigaciones que limitan el número de conexiones CDN-origen y restringen el tamaño de las cabeceras en la tabla dinámica, según la sección de divulgación del documento, que también registra recompensas por errores de aproximadamente $350 de Baidu y $150 de Tencent. Los otros cuatro proveedores reconocieron la divulgación y estaban discutiendo los hallazgos internamente. No se reporta si los ataques fueron re-probados después de que Baidu y Tencent aplicaran sus mitigaciones, ni si el código de ataque o el marco de medición se publicarán.
El trabajo es de investigadores de la Universidad Nacional de Singapur, la Universidad de Fuzhou, la Universidad de Sheffield y la Universidad Johns Hopkins. Se presentará en el Simposio sobre Sistemas Distribuidos Confiables en Roma, del 22 al 24 de septiembre de 2026. La tabla dinámica QPACK fue objeto de una vulnerabilidad separada divulgada el 8 de julio, cuando el investigador de FoxIO, Sébastien Féry, reportó que unos 260 bytes de tráfico QPACK compatible con la especificación podían bloquear cualquier servidor que ejecutara XQUIC, la biblioteca QUIC y HTTP/3 de Alibaba, que proporciona soporte HTTP/3 para el servidor web Tengine que Alibaba ejecuta en su infraestructura de nube y CDN.
Esto ocurre mientras el Proyecto OpenSSL, el 13 de agosto, reveló CVE-2026-14456, una vulnerabilidad de baja gravedad en la que un servidor QUIC pone en cola canales entrantes para ID de conexión de destino desconocidos sin límite; la corrección introduce un límite para conexiones pendientes, fijado por defecto en 256. Cloudflare, en su informe de amenazas DDoS H1 2026 publicado la misma semana, dijo que el 'centro de gravedad de los vectores de ataque se desplazó de inundaciones de botnets a reflexión y amplificación', con ataques basados en DNS representando el 34.3% de toda la actividad de capa de red en la primera mitad de 2026.
Deja una respuesta