Una nueva técnica de denegación de servicio preocupa especialmente a administradores de sistemas y responsables de infraestructuras digitales. Bautizada como HTTP/2 Bomb, esta modalidad de ataque aprovecha características propias del protocolo HTTP/2 para provocar un consumo masivo de memoria en servidores web, llegando a inutilizarlos en apenas unos segundos.
Lo más llamativo de esta amenaza es que no requiere grandes botnets ni redes distribuidas de equipos comprometidos.
Según la información disponible, un único ordenador doméstico conectado mediante una línea de 100 Mbps puede generar suficiente presión para dejar fuera de servicio servidores empresariales con decenas de gigabytes de memoria RAM.
La técnica afecta a configuraciones predeterminadas de algunos de los servidores web más utilizados del mundo, entre ellos NGINX, Apache HTTP Server, Microsoft IIS, Envoy y Cloudflare Pingora.
Cómo funciona HTTP/2 Bomb
El ataque combina dos mecanismos ya conocidos dentro del ámbito de la ciberseguridad, pero los une de una forma especialmente efectiva.
Por un lado, explota el sistema HPACK, el método de compresión de cabeceras incluido en HTTP/2. Este mecanismo fue diseñado para reducir el tráfico y mejorar el rendimiento de las comunicaciones web, pero puede utilizarse de forma maliciosa para provocar una amplificación desproporcionada del consumo de memoria.
El atacante introduce determinados encabezados dentro de la tabla dinámica de HPACK y posteriormente los referencia repetidamente mediante índices extremadamente pequeños.
Aunque el volumen de datos enviado es mínimo, el servidor necesita reservar una cantidad mucho mayor de memoria para procesar cada solicitud.
En algunos escenarios observados durante las pruebas, un único byte transmitido por el atacante terminaba generando miles de bytes de ocupación en el servidor. Las tasas de amplificación registradas alcanzaron aproximadamente 5.700 a 1 en Envoy y cerca de 4.000 a 1 en Apache HTTP Server.
El segundo elemento que multiplica el impacto
La verdadera peligrosidad aparece cuando esa memoria no puede liberarse.
La segunda fase del ataque utiliza una técnica similar a la empleada históricamente por los ataques Slowloris. Mediante la manipulación del control de flujo de HTTP/2, el atacante anuncia ventanas de recepción de tamaño cero, impidiendo que las respuestas del servidor se completen correctamente.
Como consecuencia, los recursos asignados permanecen ocupados durante largos periodos de tiempo. El servidor sigue manteniendo información en memoria mientras espera que la comunicación continúe, lo que provoca una acumulación progresiva hasta alcanzar niveles críticos.
Esta combinación convierte un simple intercambio de datos aparentemente inofensivo en una herramienta capaz de consumir enormes cantidades de memoria en cuestión de segundos.
Resultados de las pruebas realizadas
Los ensayos llevados a cabo por los investigadores muestran cifras especialmente preocupantes.
Entre los resultados obtenidos destacan:
- Envoy 1.37.2 agotó 32 GB de memoria RAM en aproximadamente 10 segundos.
- Apache HTTP Server 2.4.67 consumió 32 GB en unos 18 segundos.
- NGINX 1.29.7 alcanzó los 32 GB en cerca de 45 segundos.
- Microsoft IIS sobre Windows Server 2025 llegó a ocupar 64 GB de memoria en unos 45 segundos.
Estas cifras reflejan la capacidad del ataque para provocar interrupciones severas incluso en servidores con recursos elevados y configuraciones empresariales.
Además, los investigadores señalaron que un único cliente conectado puede llegar a mantener retenidos más de 32 GB de memoria del servidor en apenas veinte segundos, una situación que normalmente requeriría una infraestructura ofensiva mucho más compleja.
Por qué las defensas tradicionales pueden no ser suficientes
Uno de los aspectos más preocupantes de HTTP/2 Bomb es que consigue esquivar algunos de los mecanismos de protección que actualmente utilizan numerosos servidores.
Las defensas convencionales suelen centrarse en limitar el tamaño total de las cabeceras HTTP o en restringir determinadas peticiones sospechosas. Sin embargo, en este caso los encabezados utilizados son muy pequeños y aparentemente legítimos.
La amplificación no proviene del volumen de datos transmitidos, sino de cómo el servidor administra internamente la memoria necesaria para procesar dichas solicitudes.
Esto dificulta la detección temprana y permite que el ataque se mantenga dentro de parámetros que inicialmente podrían parecer normales.
Plataformas afectadas y estado de los parches
No todos los entornos son igualmente vulnerables. Algunos fabricantes ya han comenzado a desplegar actualizaciones para mitigar el problema.
NGINX corrigió la vulnerabilidad en la versión 1.29.8 mediante la incorporación de una nueva directiva denominada «max_headers», destinada a controlar de forma más estricta la gestión de cabeceras.
Por su parte, Apache HTTP Server solucionó el problema en mod_http2 2.0.41. La vulnerabilidad quedó registrada con el identificador CVE-2026-49975.
Sin embargo, en el momento actual todavía no existen actualizaciones públicas para Microsoft IIS, Envoy o Cloudflare Pingora.
Medidas recomendadas para reducir el riesgo
Los expertos aconsejan revisar cuanto antes las configuraciones HTTP/2 expuestas a Internet y aplicar las actualizaciones disponibles.
También recomiendan desplegar proxies inversos, cortafuegos de aplicaciones web y sistemas de filtrado capaces de imponer límites estrictos sobre el número de cabeceras aceptadas por cada conexión.
Las organizaciones que operan detrás de redes CDN o plataformas de distribución de contenido cuentan con una capa adicional de protección, ya que los atacantes no acceden directamente al servidor vulnerable.
En los casos donde resulte viable desde el punto de vista operativo, otra medida temporal consiste en desactivar HTTP/2 hasta que los fabricantes publiquen soluciones definitivas.
