HTTP/2 Bomb CVE-2026-49975: DoS que tira proxies

Durante años, las debilidades de HTTP/2 se conocían por separado: la amplificación de HPACK por un lado, los ataques tipo Slowloris por el otro. El HTTP/2 Bomb (CVE-2026-49975) las encadena y el resultado es brutal: una sola máquina en una conexión hogareña de 100 Mbps deja un servidor sin memoria en segundos. No hace falta botnet, ni volumen, ni nada exótico. Solo un cliente HTTP/2 que sabe pedir mal.

El HTTP/2 Bomb (CVE-2026-49975) es una vulnerabilidad de denegación de servicio (DoS) remota divulgada el 2 de junio de 2026 por la firma Calif. Encadena una "bomba" de compresión HPACK con un bloqueo de la ventana de control de flujo de HTTP/2 para agotar la memoria del servidor. Afecta las configuraciones por defecto de NGINX, Apache HTTP Server, Microsoft IIS, Envoy y Cloudflare Pingora, y la explotación no requiere autenticación ni un gran ancho de banda.

¿Por qué un solo atacante puede tirar un servidor sin botnet?

HTTP/2 Bomb (CVE-2026-49975): un DoS que voltea proxies en segundos

Porque el ataque es de amplificación asimétrica: cada byte que el atacante manda por el cable le cuesta al servidor cientos o miles de bytes de RAM. Según el análisis técnico de Calif, la relación de amplificación llega a ~5.700:1 en Envoy. Eso rompe el supuesto clásico de que para tumbar un servicio necesitás inundarlo con tráfico. Acá el trabajo lo hace la víctima al descomprimir y retener datos.

La mecánica combina dos piezas conocidas que nunca se habían usado juntas de esta forma:

Bomba de referencia indexada HPACK. El atacante siembra una cabecera grande una vez en la tabla dinámica de HPACK y después la referencia miles de veces con punteros indexados de 1 byte. Un byte en el cable se convierte en una asignación de cabecera completa del lado del servidor, repetida miles de veces por request.
Window stall estilo Slowloris. El cliente anuncia una ventana de control de flujo de cero bytes, así el servidor no puede terminar de enviar su respuesta. Después manda frames WINDOW_UPDATE de 1 byte cada tanto para resetear el timeout, dejando toda esa memoria clavada y sin liberar.

¿Cuál es el bug de fondo que hace posible el ataque?

La raíz es una regla del propio estándar que los servidores no estaban contabilizando bien. Según Calif, "RFC 9113 §8.2.3 explícitamente permite dividir la cabecera Cookie en un campo por crumb, y estos servidores no estaban contando los crumbs contra el límite". En criollo: el protocolo autoriza partir una cookie en muchos fragmentos, y las implementaciones aplicaban su límite de cabeceras al conjunto, no a cada fragmento. Ese descuido es el que permite inflar la asignación de memoria sin superar ninguna cota "oficial".

El detalle jugoso del hallazgo, y de ahí el título del post original de Calif ("Codex Discovered a Hidden HTTP/2 Bomb"), es que el patrón lo destapó una herramienta de IA revisando código, no un fuzzer clásico. Es un ejemplo concreto de análisis asistido encontrando una interacción sutil entre dos partes de un RFC.

¿Qué servidores afecta y con qué intensidad?

Afecta las configuraciones por defecto de los cinco stacks más comunes en el borde de internet, pero el impacto varía muchísimo según la implementación. Estas son las cifras medidas por los investigadores de Calif (verificá siempre contra tu versión exacta):

Servidor	Amplificación	Impacto de memoria
Envoy	~5.700:1	~32 GB en ~10 s
Apache httpd	~4.000:1	~32 GB en ~18 s
nginx	~70:1	~32 GB en ~45 s
Microsoft IIS	~68:1	~64 GB en ~45 s

De acuerdo con la cobertura de The Hacker News y BleepingComputer, el problema alcanza potencialmente a más de 880.000 sitios que corren HTTP/2 con configuración por defecto. Como el vector está en la capa de protocolo, la superficie no son solo los sitios web: incluye APIs, reverse proxies, load balancers y cualquier servicio con HTTP/2 expuesto.

¿Ya hay parches disponibles?

Sí, para varias implementaciones, aunque el despliegue fue escalonado y algunas quedaron expuestas más tiempo. Según el timeline de Calif y el boletín RHSB-2026-007 de Red Hat (que agrupa CVE-2026-49975 junto a CVE-2026-47774), este es el estado general:

nginx: parcheado primero. El fix entró en la rama 1.29.8 en abril de 2026, antes de la divulgación pública.
Apache httpd: fix el mismo día del reporte. Calif reportó el 27 de mayo y Apache corrigió en esa misma fecha; las builds con la corrección salieron a fines de mayo y mediados de junio.
Envoy: parche cerca de la divulgación. Publicó mitigaciones alrededor del 2-3 de junio de 2026.
Microsoft IIS y Cloudflare Pingora: revisá el estado actual. Al momento de la divulgación varias configuraciones por defecto seguían expuestas; consultá los avisos oficiales de cada proveedor para tu versión.

Como el PoC ya es público —hay repositorios con código de prueba de concepto y análisis técnico circulando— la ventana entre "leí la noticia" y "alguien lo prueba contra mi endpoint" es corta. La prioridad no es entender cada frame de HTTP/2, es confirmar tu versión y aplicar el update.

¿Qué puede hacer hoy un developer con servicios en producción?

Actualizar a la versión parcheada de tu servidor es la mitigación real; todo lo demás es contención temporal. Los pasos concretos, del más al menos importante:

Identificá qué corre en tu borde y su versión. Un nginx -v, httpd -v o el equivalente de tu proxy te dice si estás por debajo del release con el fix. Si tenés Envoy o Pingora al frente, revisá el aviso del vendor para tu build.
Aplicá el parche. Es la única solución que ataca la causa. En stacks self-hosted esto suele ser un apt upgrade o rebuild de la imagen del contenedor con la versión corregida.
Si no podés parchear ya, endurecé los límites de HTTP/2. Bajar los máximos de cabeceras, el tamaño de la tabla HPACK y las concurrencias reduce el margen de amplificación. En NGINX mirá directivas como large_client_header_buffers y los límites de http2; en Apache, los H2* de mod_http2. Ajustá con criterio y probá en staging.
Como último recurso, deshabilitá HTTP/2 en endpoints públicos sin parchear. Volver a HTTP/1.1 en el listener expuesto corta el vector a costa de perder multiplexación. Es un torniquete, no una cura.
Vigilá la memoria del proceso del proxy. Un pico anómalo de RAM en el borde, con poco tráfico entrante, es exactamente la firma de este ataque. Alertas sobre uso de memoria del proceso te dan detección temprana.

Si administrás tu propio servidor cloud, este caso es un recordatorio de por qué conviene mantener el stack del borde en versiones vigentes y no clavar una config "que funciona" durante meses: acá el default cómodo era justamente el problema. Vendors de seguridad como Fortinet, Imperva y HAProxy ya publicaron reglas y guías de mitigación para clientes gestionados.

¿En qué se parece y en qué se diferencia de ataques HTTP/2 anteriores?

Es el mismo linaje que HTTP/2 Rapid Reset y las bombas de descompresión clásicas, pero con una vuelta de tuerca en la combinación. Rapid Reset (2023) explotaba el ciclo abrir/cancelar streams para saturar CPU; las "zip bombs" abusaban de la descompresión. El HTTP/2 Bomb toma la amplificación por compresión de HPACK y le suma la retención de memoria del window stall, de modo que lo que se agota no es CPU sino RAM, y se agota rápido. Si te interesa el tema, en este blog cubrimos otra falla reciente del mismo servidor en "NGINX Rift (CVE-2026-42945): el full-chain que anula el ASLR".

Preguntas frecuentes

¿Qué es el HTTP/2 Bomb?

Es una vulnerabilidad de denegación de servicio (CVE-2026-49975) que encadena una bomba de compresión HPACK con un bloqueo de la ventana de flujo de HTTP/2 para agotar la memoria del servidor. Fue divulgada el 2 de junio de 2026 por la firma Calif.

¿Necesito una botnet para ejecutarlo?

No. Por la amplificación asimétrica —hasta ~5.700:1 en Envoy según Calif— una sola máquina en una conexión de 100 Mbps basta para tumbar un servidor vulnerable en segundos, sin volumen de tráfico.

¿Mi servidor está afectado?

Si expone HTTP/2 con configuración por defecto de NGINX, Apache httpd, Microsoft IIS, Envoy o Cloudflare Pingora en una versión previa al parche, probablemente sí. Verificá la versión exacta contra el aviso de tu proveedor.

¿Cómo lo mitigo si todavía no puedo parchear?

Endurecé los límites de HTTP/2 (tamaño de cabeceras, tabla HPACK, concurrencia) y, como último recurso, deshabilitá HTTP/2 en el endpoint público. Son medidas de contención hasta aplicar la versión corregida.

¿Hay explotación activa?

El código de prueba de concepto y los detalles técnicos son públicos, lo que baja la barrera para reproducirlo. Tratá cualquier endpoint sin parchear como expuesto y priorizá la actualización.

Fuentes: Calif — Codex Discovered a Hidden HTTP/2 Bomb · Red Hat — RHSB-2026-007 · The Hacker News · BleepingComputer · SecurityWeek