TL;DR:

Calif reveló HTTP/2 Bomb, un exploit remoto de denegación de servicio contra servidores web con HTTP/2.

La firma reportó que una sola conexión puede retener 32 GB de memoria en Apache httpd y Envoy en unos 20 segundos.

NGINX, Apache y Envoy ya tienen parches o mitigaciones; en Microsoft IIS y Cloudflare Pingora el panorama público sigue menos claro.

La bomba HTTP/2 ha sonado la alarma en el mundo de la ciberseguridad, ya que aprovecha la configuración predeterminada de servidores populares como NGINX, Apache HTTPD, Microsoft IIS, Envoy y Cloudflare Pingora. Según la compañía de seguridad Calif, el malware fue descubierto utilizando OpenAI Codex y combina dos tecnologías bien conocidas – la bomba de compresión y la persistencia de conexión que imita Slowloris – para aumentar y monopolizar drásticamente el consumo de memoria de los servidores, lo que supone un riesgo inmediato para las empresas en México y América Latina. Los sitios web, API y servicios que utilizan HTTP/2 y ejecutan software vulnerable son fácilmente inaccesibles para atacantes sin botnets

HTTP/2 Bomb es un exploit remoto de denegación de servicio que abusa de HPACK, el sistema de compresión de encabezados de HTTP/2, y de la ventana de control de flujo del protocolo para forzar asignaciones de memoria que el servidor no libera de inmediato.

"El comportamiento vulnerable existe en la configuración predeterminada de HTTP/2 de cada servidor", dijo Calif.

La parte más incómoda del hallazgo no es que exista una nueva variante de DoS. Es que toma piezas que ya estaban documentadas desde hace años y las encadena de una forma que varios servidores no bloquearon por defecto.

Calif describe el ataque como una combinación de dos movimientos:

• La bomba: el atacante usa referencias HPACK muy pequeñas para provocar miles de asignaciones de encabezados en el servidor.
• La retención: el cliente anuncia una ventana de flujo de cero bytes, lo que impide que el servidor termine la respuesta y libere memoria.
• El efecto práctico: el servidor acumula presión de RAM hasta degradarse, entrar en swap o terminar procesos por falta de memoria.

Según Calif, una computadora doméstica con conexión de 100 Mbps podría volver inaccesible un servidor vulnerable en segundos. En las pruebas citadas por la firma, un solo cliente consumió y retuvo 32 GB de memoria contra Apache httpd y Envoy en alrededor de 20 segundos.

El riesgo no está solo en HTTP/2, sino en cómo los servidores cuentan la memoria

El punto técnico clave está en que muchos límites tradicionales miran el tamaño total de los encabezados decodificados. HTTP/2 Bomb esquiva ese enfoque porque el encabezado puede ser casi vacío; el peso real aparece en la contabilidad interna que el servidor asigna por cada entrada.

En otras palabras: el problema no es únicamente cuántos bytes viajan por la red, sino cuánta memoria obliga a reservar cada byte cuando llega al servidor.

Calif reportó estos resultados de demostración:

• Envoy 1.37.2: amplificación aproximada de 5,700:1, con 32 GB en unos 10 segundos.
• Apache httpd 2.4.67: amplificación aproximada de 4,000:1, con 32 GB en unos 18 segundos.
• NGINX 1.29.7: amplificación aproximada de 70:1, con 32 GB en unos 45 segundos.
• Microsoft IIS en Windows Server 2025: amplificación aproximada de 68:1, con 64 GB en unos 45 segundos.

La compañía también anunció que Shodan ahora es compatible con HTTP/2 e identificó más de 880.000 sitios web que utilizan estos servidores. Sin embargo, esta cifra no debe interpretarse de manera general como "880.000 sitios web vulnerables", ya que muchos de estos sitios web están protegidos por CDN, tienen contramedidas o tienen diferentes configuraciones. Sin embargo, esta cifra muestra claramente el alcance de los equipos de infraestructura que deben revisarse

NGINX, Apache y Envoy ya movieron ficha; IIS y Pingora siguen bajo presión

La respuesta no ha sido pareja. NGINX incorporó la directiva max_headers en 1.29.8, con un valor predeterminado de 1,000 encabezados. La idea es simple: no basta limitar el tamaño total; también hay que limitar cuántos encabezados acepta el servidor.

Apache httpd corrigió el problema en mod_http2 v2.0.41, con un ajuste para contabilizar encabezados cookie contra LimitRequestFields. Calif señaló que, si no es posible actualizar, una mitigación temporal es desactivar HTTP/2 con Protocols http/1.1.

Envoy publicó el aviso GHSA-22m2-hvr2-xqc8 el 3 de junio de 2026. El proyecto marcó como afectadas las versiones menores a 1.39 y enlistó como versiones corregidas 1.35.11, 1.36.7, 1.37.3 y 1.38.1.

Para administradores, el checklist defensivo queda así:

• Actualizar NGINX a 1.29.8+ o desactivar HTTP/2 si no hay parche inmediato.
• Actualizar Apache httpd / mod_http2 a una versión corregida; como medida temporal, usar Protocols http/1.1.
• Actualizar Envoy a la versión parcheada correspondiente a cada rama.
• En Microsoft IIS y Cloudflare Pingora, revisar avisos oficiales y considerar desactivar HTTP/2 o poner una capa frontal que limite de forma estricta el número de encabezados por request.
• Aplicar límites de memoria por worker con contenedores, cgroups o mecanismos equivalentes para evitar que un proceso arrastre toda la máquina a swap.

La recomendación más importante es conceptual: cualquier punto que termine HTTP/2 debería limitar tanto el tamaño decodificado de encabezados como la cantidad de campos, incluyendo fragmentos cookie, y también acotar la vida de streams detenidos.

El dato incómodo: Codex no “inventó” el ataque, conectó piezas conocidas

Calif atribuye el descubrimiento a OpenAI Codex, pero el hallazgo no significa que el modelo haya creado una clase de ataque desde cero. El valor estuvo en encadenar patrones conocidos: el abuso de HPACK y una retención de recursos similar a Slowloris.

Ese detalle importa para equipos de seguridad. Si un agente de IA puede leer diferencias públicas de código, conectar mitigaciones y convertirlas en un exploit funcional, la ventana entre “parche publicado” y “ataque replicable” se vuelve más corta.

El caso también obliga a revisar cómo se comunican los parches. Un commit defensivo puede revelar suficiente información para que otros reconstruyan el vector. No es una razón para ocultar correcciones, pero sí para acelerar pruebas, actualizaciones y mitigaciones en producción.

Para empresas con portales públicos, APIs, e-commerce o servicios críticos, HTTP/2 Bomb no es una nota técnica de nicho. Es un recordatorio de que una configuración predeterminada puede ser segura hasta que alguien encuentra el ángulo donde el protocolo, la memoria y el tiempo juegan a favor del atacante.

Fuentes: 1