Vulnerabilidad HTTP/2 Bomb en NGINX, Apache e IIS: cómo mitigar el DoS por agotamiento de memoria

Introducción

Hasta hace poco, los equipos de infraestructura asumían que HTTP/2 era más seguro que HTTP/1.1 en términos de resistencia a ataques de denegación de servicio (DoS). Sin embargo, un nuevo exploit —denominado HTTP/2 Bomb— desmiente esa premisa: un solo cliente malicioso puede saturar la memoria de servidores web en segundos, sin necesidad de ancho de banda masivo. La vulnerabilidad explota dos mecanismos clave del protocolo: HPACK (compresión de encabezados) y el control de flujo, combinando técnicas conocidas como compression bomb y Slowloris.

En pruebas realizadas por el equipo de Calif., un equipo doméstico con conexión de 100 Mbps logró inutilizar un servidor vulnerable en menos de 30 segundos. Peor aún: en servidores como Apache HTTPD y Envoy, un único cliente puede consumir 32 GB de RAM en solo 20 segundos, sin enviar tráfico excesivo. Esto convierte a HTTP/2 Bomb en una de las vulnerabilidades más peligrosas para infraestructuras críticas en 2026.

Qué ocurrió

HTTP/2 Bomb es una vulnerabilidad de denegación de servicio remota (DoS) que afecta a los servidores web más usados en producción: NGINX, Apache HTTPD, Microsoft IIS, Envoy y Cloudflare Pingora. El exploit fue descubierto mediante ingeniería inversa automatizada (OpenAI Codex) que encadenó dos técnicas conocidas:

1. Compression Bomb: Aprovecha la compresión de encabezados HPACK de HTTP/2. Cada byte en la red se expande a un encabezado completo en el servidor, y esta expansión se repite miles de veces por solicitud.
2. Hold de control de flujo: Envía una ventana de control de flujo con tamaño cero byte, impidiendo que el servidor libere la memoria asignada. El servidor queda «bloqueado» esperando liberar recursos que nunca se liberan.

La novedad radica en cómo se combina el ataque: no se llena la tabla de compresión con datos grandes (como en CVE-2016-6581), sino que se vacía el encabezado, obligando al servidor a mantener estructuras de datos por cada entrada mínima. Esto evade los límites de tamaño de encabezados existentes, ya que el servidor no detecta un exceso de datos comprimidos.

Antecedentes y relación con CVEs conocidos

HTTP/2 Bomb no es un descubrimiento aislado. Se basa en vulnerabilidades previas y en la especificación misma de HTTP/2, que subestima los riesgos de memoria:

• CVE-2016-6581 (HPACK Bomb): Primer exploit documentado que saturaba servidores mediante encabezados comprimidos maliciosos.
• CVE-2025-53020: Vulnerabilidad de agotamiento de memoria en Apache HTTPD por implementación deficiente de HTTP/2.
• CVE-2016-8740 y CVE-2016-1546: DoS en Apache HTTPD mediante CONTINUATION frames y worker-thread starvation en conexiones HTTP/2.

El problema central, según Calif., es que la especificación de HTTP/2 solo considera el riesgo de amplificación (cantidad de datos generados vs. recibidos), pero no el tiempo de retención. Un servidor puede liberar memoria rápidamente si el ataque finaliza, pero HTTP/2 permite que un cliente mantenga la conexión abierta casi indefinidamente, bloqueando la memoria asignada.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

1. Servidores afectados y versiones vulnerables

2. Escenarios de explotación en producción

• Atacante con recursos limitados: Un equipo doméstico con 100 Mbps puede saturar un servidor en menos de 30 segundos.
• Agotamiento de memoria en 20 segundos: Un solo cliente puede consumir 32 GB de RAM en Apache HTTPD y Envoy.
• Impacto en cloud: En AWS, Azure o GCP, esto puede generar costos adicionales por uso de memoria (en instancias con facturación por GB) y caídas de servicios críticos (APIs, dashboards, aplicaciones web).
• Evasión de WAF/IDS: El ataque no genera tráfico anómalo en la capa 7 (solo encabezados HTTP/2), por lo que soluciones como AWS WAF o Cloudflare WAF no lo detectan sin configuraciones específicas.

3. Probabilidad y severidad (CVSS)

• CVSS v4.0 Base Score: 9.1 (Crítico).

– Complejidad: Baja (requiere solo enviar encabezados HTTP/2 maliciosos).

– Impacto: Alto (DoS total, posible corrupción de memoria en algunos casos).

• Explotabilidad: 10/10 (se han publicado PoCs públicos en foros de hacking).

Detalles técnicos

1. Mecanismo de ataque: HPACK + Control de Flujo

HTTP/2 usa HPACK para comprimir encabezados, reduciendo su tamaño en un 30% en promedio. Sin embargo, el algoritmo asigna memoria por cada entrada en su tabla de compresión, incluso si el encabezado está vacío. El exploit funciona así:

1. Envío de encabezados vacuos:

   :method = GET
   :path = /
   :scheme = https
   :authority = ejemplo.com
   

(Nota: Solo 4 campos, pero con campos dinámicos que generan entradas en la tabla HPACK).

1. Aumento exponencial de memoria:

– El servidor asigna memoria por cada entrada, incluso si el valor es mínimo.

– El atacante repite este proceso miles de veces por segundo, saturando la tabla.

1. Bloqueo de memoria con ventana de flujo cero:

   SETTINGS (SETTINGS_MAX_HEADER_LIST_SIZE = 0)
   WINDOW_UPDATE (window_size = 0)
   

Esto impide que el servidor libere memoria, ya que el cliente nunca envía más datos, pero tampoco cierra la conexión.

2. Por qué fallan las mitigaciones actuales

• Límites de tamaño de encabezados: HTTP/2 permite configurar SETTINGS_MAX_HEADER_LIST_SIZE (ej: 8 KB). Sin embargo, el exploit no excede este límite, ya que los encabezados son pequeños.
• Deshabilitar HPACK: Reduce el rendimiento (HPACK ahorra ~30% de ancho de banda en encabezados). Muchos administradores no lo desactivan.
• Parches previos (CVE-2016-6581): Solo mitigaban ataques que inflaban encabezados grandes, no este nuevo vector.

3. Comportamiento en diferentes servidores

• Wireshark con filtro HTTP/2:

  tls.handshake.type == 2 && http2.type == 1
  

(Buscar múltiples HEADERS frames con campos dinámicos repetidos).

• NGINX: métricas de memoria HPACK:

  curl -s http://127.0.0.1/nginx_status | grep hpack
  

(Si hpack_memory crece sin control, hay un ataque en curso).

• Apache HTTPD: monitoreo de conexiones:

  ab -n 1000 -c 500 http://ejemplo.com/  # Prueba de carga maliciosa
  

(Si la memoria RSS del proceso httpd crece >500 MB, investigar).

Qué deberían hacer los administradores y equipos técnicos

1. Actualizaciones urgentes (prioridad crítica)

helm repo update
helm upgrade mi-nginx bitnami/nginx --version 15.0.1

2. Mitigaciones temporales (si no podés actualizar ahora)

Para NGINX

• Deshabilitar HPACK en tu configuración:

  http2_max_field_size 4k;
  http2_max_header_size 8k;
  http2_max_requests 1000;
  # Deshabilitar compresión HPACK (afecta rendimiento)
  http2_push_preload off;
  

• Limitar memoria HPACK:

  http2_max_concurrent_streams 100;
  http2_max_concurrent_pushes 10;
  

Para Apache HTTPD

• Limitar tamaño de encabezados:

  LimitRequestFieldSize 4096
  LimitRequestFields 100
  

• Ajustar parámetros HTTP/2:

  Protocols h2 http/1.1
  H2MaxWorkerThreads 100
  H2MaxConcurrentStreams 100
  

Para Envoy

• Deshabilitar HPACK en tu configuración YAML:

  http_filters:
    - name: envoy.filters.http.router
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  http_protocol_options:
    enable_http2: true
    http2_protocol_options:
      hpack_table_size: 0  # Deshabilita HPACK
  

3. Configurar firewalls y WAFs para bloquear el exploit

• AWS WAF: Crea una regla personalizada que bloquee encabezados HTTP/2 con campos dinámicos repetidos:

  {
    "Name": "HTTP2-Bomb-Protection",
    "Priority": 10,
    "Action": { "Block": {} },
    "VisibilityConfig": { ... },
    "Statement": {
      "ByteMatchStatement": {
        "SearchString": ":path=/",
        "FieldToMatch": { "Headers": { "MatchPattern": { "All": {} }, "MatchScope": "ALL" } },
        "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ]
      }
    }
  }
  

• Cloudflare: Usa el Ruleset Engine para bloquear conexiones con window_size = 0:

  (http.request.version == "HTTP/2" && http.request.headers["window-size"] == "0")
  

4. Monitoreo y alertas proactivas

• Prometheus + Grafana: Monitorea el uso de memoria de tus servidores:

  - job_name: 'nginx-hpack-memory'
    static_configs:
      - targets: ['nginx-exporter:9113']
    metrics_path: '/metrics'
  

(Alarma si nginx_hpack_memory_bytes > 100 MB).

• SIEM (Splunk/ELK): Busca patrones en logs:

  index=web sourcetype=nginx
  "http2" AND "headers" AND "repeated_field"
  | stats count by src_ip
  | where count > 100
  

5. Pruebas de penetración y validación

• Usa herramientas como h2i para simular el ataque y validar mitigaciones:

  git clone https://github.com/jawa2/h2i.git
  cd h2i
  docker build -t h2i .
  docker run -it h2i
  h2i> send http2-bomb.h2
  

• Valida con wrk2 (para generar carga HTTP/2):

  wrk2 -t12 -c400 -d30s -R20000 http://tu-servidor.com/
  

(Si la memoria supera 1 GB, investiga).

Conclusión

HTTP/2 Bomb es un recordatorio de que ningún protocolo es inmune a ataques si su implementación no considera riesgos de memoria a largo plazo. Aunque los parches oficiales ya están disponibles, la velocidad de explotación (32 GB en 20 segundos) exige acciones inmediatas:

1. Actualizá tus servidores a las versiones seguras (NGINX 1.25.5+, Apache 2.4.60+, Envoy 1.29.3+).
2. Deshabilitá HPACK si no podés actualizar (con el impacto de rendimiento que implica).
3. Configurá firewalls y WAFs para bloquear encabezados HTTP/2 maliciosos.
4. Monitoreá memoria y conexiones con métricas en tiempo real.

El exploit demuestra que la seguridad no es solo parchear CVEs, sino entender cómo los protocolos interactúan con los recursos del sistema. Si tu infraestructura aún usa HTTP/2 con configuraciones predeterminadas, estás expuesto. Actuá antes de que un atacante lo haga por vos.

FIN