✨︎ Resumen (TL;DR):
- Calif descubrió HTTP/2 Bomb, un exploit de denegación de servicio (DoS) remoto que abusa de HPACK y de la ventana de control de flujo en HTTP/2.
- Una sola conexión desde una computadora casera de 100 Mbps puede saturar y retener 32 GB de RAM en servidores vulnerables en unos 20 segundos.
- Desarrolladores de NGINX, Apache y Envoy ya lanzaron parches urgentes, mientras que la situación en Microsoft IIS y Cloudflare Pingora sigue bajo análisis.
La empresa de seguridad Calif reveló un exploit remoto de denegación de servicio (DoS) llamado HTTP/2 Bomb, que permite a atacantes individuales colapsar servidores web populares sin necesidad de una botnet. Al combinar técnicas de compresión y persistencia de datos, el ataque secuestra la memoria RAM de sistemas vulnerables como NGINX, Apache, Envoy, Microsoft IIS y Cloudflare Pingora, dejando sitios web y APIs completamente inaccesibles en cuestión de segundos.
HTTP/2 Bomb es un exploit de denegación de servicio que abusa del sistema de compresión de encabezados HPACK de HTTP/2 y de la ventana de control de flujo del protocolo para forzar asignaciones de memoria masivas que el servidor no puede liberar de inmediato.
De acuerdo con la investigación, el fallo aprovecha la configuración predeterminada de estos servidores. El exploit encadena dos mecanismos que ya se conocían en el ámbito de la ciberseguridad, pero que no se habían combinado de esta forma en las configuraciones por defecto de la industria.
El ataque funciona en dos fases básicas: la bomba y la retención. Primero, el atacante envía referencias de HPACK muy pequeñas para forzar miles de asignaciones de encabezados internos. Luego, el cliente anuncia una ventana de flujo de cero bytes, obligando al servidor a retener la respuesta sin liberar la memoria RAM consumida.
El impacto real en la memoria RAM
El problema principal radica en cómo los servidores miden el uso de la memoria. La mayoría de los límites tradicionales revisan el peso total de los encabezados ya decodificados. Sin embargo, HTTP/2 Bomb pasa desapercibido porque el encabezado recibido viaja casi vacío; la carga real ocurre dentro de la contabilidad interna del servidor cuando intenta procesar los datos.
En las pruebas controladas por Calif, los resultados de amplificación de memoria fueron críticos:
- Envoy 1.37.2: Amplificación de 5,700:1, consumiendo 32 GB de RAM en 10 segundos.
- Apache httpd 2.4.67: Amplificación de 4,000:1, consumiendo 32 GB de RAM en 18 segundos.
- NGINX 1.29.7: Amplificación de 70:1, consumiendo 32 GB de RAM en 45 segundos.
- Microsoft IIS en Windows Server 2025: Amplificación de 68:1, consumiendo 64 GB de RAM en 45 segundos.
Aunque la herramienta de escaneo Shodan identificó más de 880,000 servidores expuestos a nivel global, Calif aclara que muchos de estos sitios cuentan con protección de CDN o configuraciones personalizadas que evitan el ataque directo. Aun así, la cifra demuestra la escala de la infraestructura que requiere revisión inmediata.
Parches disponibles y medidas de mitigación
Los equipos de desarrollo de las principales herramientas ya comenzaron a distribuir parches de seguridad:
- NGINX: Incorporó la directiva
max_headersen la versión 1.29.8, la cual establece un límite predeterminado de 1,000 encabezados para evitar abusos en la cantidad de campos aceptados. - Apache httpd: Solucionó el problema en
mod_http2v2.0.41 mediante una contabilidad que asocia las cookies al límiteLimitRequestFields. Los administradores que no puedan actualizar de inmediato pueden desactivar temporalmente HTTP/2 con la directivaProtocols http/1.1. - Envoy: Publicó el aviso de seguridad GHSA-22m2-hvr2-xqc8 el 3 de junio de 2026. Las versiones afectadas son las menores a la 1.39, y los parches oficiales se integraron en las ramas 1.35.11, 1.36.7, 1.37.3 y 1.38.1.
Para servidores como Microsoft IIS y Cloudflare Pingora, se recomienda implementar una capa de seguridad externa para filtrar de manera estricta los encabezados o desactivar HTTP/2 de ser necesario. Adicionalmente, limitar la memoria por worker usando contenedores o cgroups evita que un proceso comprometido consuma la memoria de toda la máquina física.
Inteligencia artificial en el descubrimiento de exploits
Un detalle técnico relevante es que Calif descubrió este exploit utilizando OpenAI Codex. Esto no significa que el modelo de lenguaje haya diseñado una técnica de ataque inédita, sino que logró conectar y encadenar vulnerabilidades previamente documentadas como HPACK y el patrón de persistencia de conexión Slowloris.
Este hecho reduce los tiempos de reacción para los equipos de TI. Si un modelo de inteligencia artificial puede automatizar el desarrollo de exploits funcionales a partir de commits públicos y parches de código, la brecha de tiempo para actualizar los servidores se vuelve crítica para la seguridad de la infraestructura digital.
