HTTP/2 Bomb: la vulnerabilidad que puede vaciar la RAM de tus servidores en segundos

Un nuevo método de denegación de servicio bautizado por sus descubridores como HTTP/2 Bomb demuestra que la combinación de técnicas ya conocidas puede volver vulnerables a servidores modernos en cuestión de segundos: HPACK (la compresión de cabeceras de HTTP/2) se usa para amplificar el uso de memoria y el control de flujo de HTTP/2 se manipula para retener indefinidamente esa memoria asignada.

Según el informe técnico publicado por los investigadores de Calif, y disponible en su blog, una sola máquina doméstica con una conexión de 100 Mbps puede forzar a servidores como Envoy, Apache httpd, NGINX o IIS a consumir decenas de gigabytes de RAM en segundos; los experimentos reproducidos por el equipo muestran ratios de amplificación extremos —hasta 5.700 bytes consumidos por cada byte enviado en el caso de Envoy— y agotamientos de 32–64 GB en menos de un minuto en configuraciones por defecto. Más detalles y contexto del descubrimiento están en el comunicado de Calif: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb.

La primera «pata» del ataque explota cómo HPACK mantiene una tabla dinámica de entradas de cabecera: el atacante inserta una entrada pequeña y la referencia de forma repetida usando su representación indexada de un byte, logrando que una mínima cantidad de datos de red provoque gran cantidad de memoria interna por la contabilidad y estructuras que el servidor reserva para cada cabecera. La segunda «pata» aprovecha el mecanismo de control de flujo de HTTP/2: el cliente anuncia una ventana de cero bytes y evita que la respuesta se complete, mientras el servidor envía ráfagas pequeñas de WINDOW_UPDATE o mantiene el estado de la conexión para evitar tiempo de espera; el resultado es que la memoria reservada no se libera.

Este enfoque evade medidas tradicionales que limitan el tamaño total de cabeceras decodificadas porque las cabeceras usadas en la explotación son intencionadamente pequeñas; la amplificación ocurre en la gestión interna por cabecera y en estructuras relacionadas con el estado de flujo. La especificación de HPACK reconoce riesgos de amplificación de memoria, pero los investigadores señalan que no aborda adecuadamente el efecto combinado con la retención indefinida vía control de flujo: la interacción entre subsistemas es lo que provoca el impacto catastrófico.

Calif publicó ya pruebas de concepto en GitHub, por lo que operadores y equipos de seguridad deben actuar con prudencia y premura: https://github.com/califio/publications/tree/main/MADBugs/http2-bomb. También es recomendable repasar la especificación de HPACK para entender la raíz del problema técnico: https://httpwg.org/specs/rfc7541.html.

Algunos proveedores y proyectos ya han lanzado mitigaciones: NGINX introdujo la directiva max_headers en la versión 1.29.8 y Apache corrigió mod_http2 en la versión señalada por el equipo; sin embargo, a fecha de este informe no existían parches oficiales para todas las implementaciones afectadas, incluyendo ciertas versiones de Envoy, Microsoft IIS o el motor Pingora de Cloudflare. Donde no haya parche disponible, las recomendaciones pragmáticas son deshabilitar HTTP/2 si es viable, o colocar un proxy inverso/CDN que filtre y limite el número de cabeceras y controles de flujo antes de que lleguen al servidor de origen.

Para equipos de operaciones y respuesta a incidentes, las acciones concretas que conviene priorizar incluyen aplicar parches disponibles de inmediato, revisar la exposición de endpoints HTTP/2 en la infraestructura pública, habilitar límites estrictos por conexión (número máximo de cabeceras y de streams simultáneos), y garantizar que los proxies o WAFs aplican umbrales duros. Además, establecer límites de recursos por proceso/worker y reglas del kernel (OOM-killer y cgroups) ayuda a contener el daño cuando la memoria empieza a crecer.

En cuanto a detección, los indicadores tempranos son patrones inusuales de streams en estado «half-open» o con ventanas de flujo persistentes en cero, un incremento rápido en el uso de memoria por procesos HTTP/2, y un número elevado de entradas repetidas en los contadores de cabeceras decodificadas. Monitorizar métricas de conexión, tiempos de respuesta y contadores internos del módulo HTTP/2 de cada servidor facilita identificar intentos de explotación antes de que la máquina quede inutilizable.

Este hallazgo también tiene una dimensión relevante para la comunidad: fue descubierto con ayuda de un agente de software (Codex) coordinado por investigadores humanos, lo que subraya cómo herramientas de IA pueden acelerar la identificación de vectores complejos pero también cómo su uso requiere normas de divulgación responsable. La presentación técnica completa se hará pública en la conferencia Real World AI Security; mientras tanto, la existencia de PoC obliga a actuar como si el riesgo fuera real y explotable.

Si tu servicio sirve tráfico público, prioriza un inventario rápido de qué componentes exponen HTTP/2, actualiza NGINX/Apache cuando corresponda y, si no puedes parchear inmediatamente, coloca un CDN/proxy que haga la validación y limite conteos de cabeceras por conexión. Documenta las medidas y pruebas de mitigación en tu playbook de incidentes: la rapidez de detección y la aplicación de límites por conexión son la diferencia entre un incidente menor y una caída completa del servicio.

Por último, la naturaleza del problema recuerda que la seguridad de protocolos modernos no depende solo de especificaciones individuales sino de sus interacciones en implementaciones reales; los equipos responsables de infraestructuras deben incorporar pruebas de estrés específicas para HTTP/2 en sus validaciones de seguridad y arquitectura defensiva.