Un nuevo ataque de denegación de servicio contra HTTP/2 ha puesto en alerta a administradores y responsables de infraestructura web. La técnica, bautizada como HTTP/2 Bomb, permite agotar la memoria de servidores ampliamente utilizados como nginx, Apache httpd, Microsoft IIS, Envoy y Cloudflare Pingora, aprovechando comportamientos presentes en sus configuraciones por defecto de HTTP/2.
Lo más llamativo del caso no es solo el impacto técnico, sino cómo fue descubierto: según el análisis publicado por Calif, el exploit fue identificado por Codex, que combinó dos técnicas conocidas desde hace años —una bomba de compresión y una retención al estilo Slowloris— para crear un ataque más eficaz. El hallazgo muestra cómo la inteligencia artificial puede acelerar el descubrimiento de vulnerabilidades al conectar piezas que ya eran públicas, pero que no se habían explotado juntas de esta forma.
Cómo funciona HTTP/2 Bomb
El ataque se apoya en HPACK, el sistema de compresión de cabeceras usado por HTTP/2. Esta tecnología permite optimizar el tráfico almacenando cabeceras repetidas en una tabla dinámica y sustituyéndolas después por referencias más pequeñas. En condiciones normales, esto mejora el rendimiento. En manos de un atacante, puede convertirse en una bomba de memoria.
La técnica consiste en introducir una cabecera en la tabla y después referenciarla miles de veces con muy pocos bytes enviados por red. Cada referencia puede obligar al servidor a reservar memoria para reconstruir la cabecera dentro de la solicitud. El atacante envía poco; el servidor consume mucho.
A esto se suma la segunda parte del ataque: una ventana de control de flujo de cero bytes. En la práctica, el cliente impide que el servidor termine de enviar su respuesta y, por tanto, evita que libere la memoria asignada. Con pequeñas actualizaciones de ventana, el atacante puede mantener viva la conexión y sostener la presión sobre la memoria durante el tiempo suficiente para degradar o inutilizar el servicio.
Un ordenador doméstico puede causar un daño enorme
Según las pruebas publicadas, un equipo doméstico con una conexión de 100 Mbps podría dejar inaccesible un servidor vulnerable en cuestión de segundos. En el caso de Apache httpd y Envoy, un solo cliente pudo consumir y retener unos 32 GB de memoria en aproximadamente 20 segundos.
Los resultados de demostración muestran amplificaciones muy distintas según el servidor: Envoy alcanzó alrededor de 5.700:1, Apache httpd unos 4.000:1, nginx cerca de 70:1 y Microsoft IIS en torno a 68:1. Aunque las cifras varían, el patrón es el mismo: poco tráfico del atacante puede traducirse en una enorme presión sobre la memoria del servidor.
El riesgo es especialmente relevante porque HTTP/2 está ampliamente desplegado. Una búsqueda citada en el análisis encontró más de 880.000 sitios web que soportan HTTP/2 y ejecutan alguno de los servidores afectados, aunque muchos de ellos se encuentran detrás de CDN, lo que dificulta su caída directa.
No es solo un problema de tamaño de cabeceras
Una de las claves del ataque está en que esquiva controles clásicos. Muchas defensas se centran en limitar el tamaño total de las cabeceras decodificadas. Pero en este caso la cabecera puede ser muy pequeña. La amplificación no viene tanto del contenido, sino del coste interno que asume el servidor al gestionar miles de referencias y estructuras asociadas.
En algunos servidores, el tratamiento de las cabeceras Cookie agrava el problema. HTTP/2 permite dividir cookies en múltiples fragmentos, y determinadas implementaciones no estaban contando esos fragmentos contra los límites esperados. Eso abre la puerta a multiplicar la presión de memoria sin activar ciertas protecciones.
Parches y mitigaciones
El investigador informó del problema a nginx en abril, y la versión 1.29.8 incorporó la directiva max_headers, con un valor por defecto de 1.000. En Apache, la corrección llegó en mod_http2 v2.0.41, donde las cabeceras cookie pasan a contar contra LimitRequestFields; el problema fue asignado como CVE-2026-49975.
Para quienes no puedan actualizar de inmediato, las recomendaciones pasan por desactivar HTTP/2 temporalmente cuando sea viable o situar el servidor detrás de una capa que imponga límites estrictos al número de cabeceras por solicitud. En nginx, la mitigación alternativa sería desactivar HTTP/2 con http2 off;. En Apache, puede usarse Protocols http/1.1 para deshabilitarlo.
En el momento de la publicación, Microsoft IIS, Envoy y Cloudflare Pingora no contaban aún con parche disponible, aunque Envoy publicó posteriormente actualizaciones que, según los autores, parecían mitigar el ataque y seguían en validación.
noticias
