HTTP/2 Bomb (CVE-2026-49975): Cómo un PC doméstico puede tumbar tu servidor en segundos

TL;DR — Lo que necesitas saber

• CVE-2026-49975 (“HTTP/2 Bomb”) tiene puntuación CVSS 9.8 y afecta a NGINX, Apache, IIS y Envoy en sus configuraciones por defecto.
• Un atacante con un PC doméstico y 100 Mbps puede agotar 32-64 GB de RAM de tu servidor en menos de un minuto.
• El exploit combina dos técnicas antiguas (HPACK Bomb + Slow Read) para evadir las defensas modernas.
• Ya existen parches para NGINX (1.29.8) y Apache. IIS y Envoy aún no tienen fix oficial.
• Si no puedes parchear hoy: deshabilita HTTP/2 o aplica límites de memoria por worker.

Qué es HTTP/2 Bomb y por qué debería preocuparte

El 2 de junio de 2026, la firma de ciberseguridad Calif reveló una vulnerabilidad crítica en el protocolo HTTP/2 que permite a un solo atacante, desde una conexión doméstica de 100 Mbps, inutilizar servidores web empresariales en cuestión de segundos. La vulnerabilidad fue catalogada como CVE-2026-49975 con una puntuación CVSS v3 de 9.8 (Crítica).

Más de 880.000 sitios web están expuestos. El ataque no requiere botnets, credenciales ni interacción del usuario. Basta con que tu servidor tenga HTTP/2 habilitado — que es la configuración por defecto en prácticamente toda la industria.

Lo más alarmante: el exploit fue descubierto usando inteligencia artificial (OpenAI Codex), que logró componer dos vulnerabilidades separadas por una década en un arma nueva que evade todas las mitigaciones existentes.

Cómo funciona HTTP/2 y por qué es vulnerable

A diferencia de HTTP/1.1, que procesaba peticiones de forma secuencial y sin estado, HTTP/2 introduce multiplexación de flujos sobre una única conexión TCP. Esto mejora la latencia enormemente, pero exige que el servidor mantenga un estado interno complejo por cada conexión.

El componente clave es HPACK (RFC 7541), el mecanismo de compresión de cabeceras. HPACK elimina la redundancia usando dos tablas: una estática (cabeceras comunes predefinidas) y una tabla dinámica que se actualiza en tiempo real. Cada cliente conectado obliga al servidor a mantener su propia tabla en memoria.

Este diseño trasladó silenciosamente una carga asimétrica hacia el servidor: por cada entrada indexada, el proceso debe asignar bloques de memoria, punteros y metadatos de control. Históricamente, esto ya abrió la puerta a ataques de agotamiento de recursos.

Anatomía técnica del exploit

La innovación de HTTP/2 Bomb no es una falla de corrupción de memoria nueva, sino la concatenación de dos vulnerabilidades lógicas que existían desde 2016, combinadas de forma que evaden todas las defensas actuales.

Fase 1: Evasión de límites con cabeceras vacías (HPACK Bomb modificado)

La “Bomba HPACK” original (CVE-2016-6581) inyectaba cabeceras masivas para lograr ratios de descompresión de 4.096x. La industria respondió con límites estrictos al tamaño total de cabeceras decodificadas.

HTTP/2 Bomb invierte la lógica: en vez de cabeceras gigantes, envía miles de cabeceras prácticamente vacías. Al no tener contenido sustancial, nunca disparan los umbrales de tamaño. Pero el servidor igual debe instanciar metadatos, punteros y bloques de control por cada entrada — consumiendo gigabytes de RAM mientras el contenido nominal pasa desapercibido para los filtros.

Fase 2: Retención de memoria con Slow Read

Para que el servidor no libere la memoria consumida, el atacante usa técnicas de lectura lenta (análogas a CVE-2016-8740):

1. Anuncia una ventana de control de flujo de cero bytes (WINDOW_UPDATE = 0)
2. El servidor suspende el envío de respuestas pero mantiene la conexión abierta
3. Señales periódicas reinician los temporizadores de inactividad

Resultado: la memoria queda secuestrada indefinidamente. El garbage collector nunca puede liberarla. El servidor entra en swap, se degrada y finalmente muere por Out-Of-Memory.

Impacto medido: la tabla que asusta

Los investigadores evaluaron la tasa de amplificación (ratio entre ancho de banda del atacante y memoria consumida en el servidor):

Incluso con el ratio “bajo” de NGINX (70:1), un solo atacante puede agotar 64 GB de RAM en menos de un minuto. Envoy con 5.700:1 es devastador.

Nota sobre Cloudflare Pingora: la versión OSS es vulnerable, pero la CDN comercial de Cloudflare no usa Pingora como proxy de ingreso HTTP/2, por lo que su red no está afectada.

Contexto histórico: la evolución de ataques a HTTP/2

HTTP/2 Bomb no surge en el vacío. Es la culminación de una década de vulnerabilidades en el protocolo:

HTTP/2 Rapid Reset (CVE-2023-44487) — Octubre 2023

Generó ataques DDoS récord: 398M rps (Google), 201M rps (Cloudflare), 155M rps (AWS). Abusaba de la multiplexación enviando flujos masivos con cancelación inmediata (RST_STREAM), agotando la CPU del servidor.

HTTP/2 Continuation Flood (CVE-2024-30255) — 2024

El atacante enviaba tramas CONTINUATION sin bandera END_HEADERS, atrapando al servidor en un bucle infinito de decodificación. Una sola conexión TCP consumía el 100% de un núcleo de CPU por cada 300 Mbit/s inyectados.

Corrupción de estado de memoria (CVE-2025-53020) — 2025

En Apache HTTPD 2.4.17-2.4.63, peticiones HTTP/2 manipuladas impedían la liberación de bloques de memoria tras finalizar la interacción. Fuga de memoria silenciosa e implacable.

HTTP/2 Bomb unifica la amplificación asimétrica de 2016, los retardos de liberación de CVE-2025-53020 y la sobrecarga sin validación de Continuation Flood. Una tormenta perfecta.

El rol de la inteligencia artificial en el descubrimiento

Los ingenieros de Calif no encontraron este exploit mediante fuzzing tradicional. Utilizaron OpenAI Codex para analizar el código fuente de los servidores web líderes y correlacionarlo con bases de datos de vulnerabilidades históricas.

La IA infirió que CVE-2016-6581 (HPACK Bomb) y las debilidades de control de flujo tipo Slow Read podían componerse en un vector que evadía todas las mitigaciones de tamaño de cabecera. Dos bugs de una década, combinados por IA, produjeron un arma nueva.

Esto marca un punto de inflexión: bases de código maduras esconden cadenas de vulnerabilidades latentes que el ojo humano no correlaciona. La ciberseguridad ofensiva automatizada acelera exponencialmente el descubrimiento de técnicas compuestas.

Parches y mitigaciones disponibles

NGINX: directiva max_headers (v1.29.8 y freenginx 1.27.1)

Se introdujo un contador de baja fricción en el parser C. Cada cabecera incrementa el valor; si se supera el umbral (típicamente 100), el servidor responde 400 Bad Request y cierra la conexión. Esto corta el ataque antes de que se instancien bloques de memoria.

Apache HTTPD: actualización mod_http2

El parche asegura que cualquier trama HTTP/2 compute contra el límite LimitRequestFields, incluyendo cookies fragmentadas entre flujos concurrentes que antes no tributaban hacia los límites globales.

IIS y Envoy: sin parche oficial aún

Para estas plataformas, aplican las mitigaciones provisionales descritas abajo.

¿Qué debo hacer ahora? — 5 pasos inmediatos

1. Identifica tu versión: ejecuta nginx -v, httpd -v o revisa tu panel de IIS. Si estás por debajo de las versiones parcheadas, eres vulnerable.

2. Aplica el parche si existe: actualiza NGINX a 1.29.8+, Apache HTTPD al último release de mayo/junio 2026.

3. Si no puedes parchear hoy — deshabilita HTTP/2: elimina h2 de la negociación ALPN en tu configuración TLS. Perderás rendimiento, pero blindas tu infraestructura.

4. Establece límites de memoria por worker: configura límites duros de RAM por proceso hijo. Si un ataque agota la cuota, el worker muere sin arrastrar al resto del servidor.

5. Filtra en el perímetro: si tienes un WAF que puede desempacar HTTP/2 cifrado, configúralo para truncar conexiones con cantidades anómalas de cabeceras antes de llegar al origen.

Perspectiva: ¿HTTP/3 es inmune?

HTTP/3, basado en QUIC/UDP, utiliza QPACK en lugar de HPACK. Este rediseño previene el bloqueo de cabeza de línea y altera radicalmente la lógica de asignación de estados. Las técnicas específicas de HTTP/2 Bomb no se traducen directamente a HTTP/3.

Sin embargo, el concepto de “amplificación por contabilidad” podría replicarse si los servidores HTTP/3 no implementan límites estrictos en el conteo de cabeceras. La lección es clara: los mecanismos defensivos deben ser restrictivos por diseño, sin confiar en la benevolencia del cliente.

Conclusión

HTTP/2 Bomb demuestra que la búsqueda de rendimiento en protocolos web introduce deudas técnicas que eventualmente son cobradas. La convergencia de IA ofensiva para descubrir vulnerabilidades compuestas obliga a los equipos de TI a abandonar la mitigación aislada de bugs y adoptar defensa en profundidad.

Si tu infraestructura corre sobre NGINX, Apache, IIS o Envoy con HTTP/2 habilitado — que probablemente sí — tienes una ventana limitada para actuar antes de que los exploits se masifiquen.

Fuentes citadas

1. CVE-2026-49975 | Tenable®
2. ‘HTTP/2 Bomb’ Exploit Knocks Web Servers Offline in Seconds — SecurityWeek
3. CERT.at Tagesmeldungen — GovCERT Austria
4. RHSB-2023-003 HTTP/2 Rapid Reset — Red Hat
5. HTTP/2 Rapid Reset: deconstructing the record-breaking attack — Cloudflare Blog
6. RFC 7541 — HPACK: Header Compression for HTTP/2
7. RFC 7541 — IETF Datatracker
8. HPACK: the silent killer (feature) of HTTP/2 — Cloudflare Blog
9. CVE-2016-6581 Detail — NVD
10. HTTP/2: In-depth analysis of the top four flaws — Imperva
11. CVE-2026-49975 — Exploits & Severity — Feedly
12. New “HTTP/2 Bomb” attack can exhaust server memory in seconds — CyberInsider
13. Fixing request smuggling vulnerabilities in Pingora OSS — Cloudflare Blog
14. Understanding the HTTP/2 Rapid Reset Attack — Qualys Blog
15. HTTP/2 Rapid Reset Vulnerability — CISA
16. HTTP/2 CONTINUATION Flood — Envoy Security Advisory (GitHub)
17. What is a continuation flood? — HAProxy
18. HTTP/2 CONTINUATION Frames Vulnerability — PSIRT FortiGuard
19. CVE-2025-53020 | Tenable®
20. CVE-2025-53020: Apache HTTP Server Use-After-Free — SentinelOne
21. Nginx 1.29.8 Update Fixes Critical Security Issues — Cyber Technology Insights
22. New Nginx 1.29.8 and FreeNginx Versions Patch Critical Security Flaws — GBHackers

En HDTI te ayudamos a proteger tu infraestructura web frente a vulnerabilidades críticas como HTTP/2 Bomb. Nuestro equipo de ciberseguridad realiza auditorías de configuración de servidores, implementa parches de emergencia y diseña arquitecturas de defensa en profundidad para que tu operación no dependa de un solo punto de fallo.

Si no estás seguro de si tus servidores están expuestos, o necesitas un plan de mitigación urgente, conversemos.

Solicita una asesoría de ciberseguridad