Durante junio de 2026 la palabra "HTTP/2 Bomb" apareció en casi todos los boletines de seguridad: un exploit que tumba servidores web enteros con una sola conexión, sin credenciales y desde una conexión hogareña. Lo llamativo no es solo el impacto —agotar 32 GB de RAM en segundos— sino que lo descubrió un modelo de IA leyendo código público. Si tenés algo en producción detrás de Nginx, Apache, IIS o Envoy, esto te toca directamente. Y hay un dato que vale la pena entender bien: HAProxy quedó de pie por diseño.
El HTTP/2 Bomb (CVE-2026-49975) es una vulnerabilidad de denegación de servicio (DoS) que afecta a servidores web como Nginx, Apache httpd, Microsoft IIS, Envoy y Cloudflare Pingora. Abusa de la compresión de cabeceras HPACK y del control de flujo de HTTP/2 para agotar la memoria del servidor desde una única conexión y sin autenticación. Fue identificada por el modelo Codex de OpenAI analizando código abierto y se divulgó en junio de 2026.
¿Por qué este DoS preocupa más que un flood clásico?
Los ataques de denegación de servicio tradicionales necesitan volumen: muchas máquinas, mucho ancho de banda, muchas peticiones. Este es distinto y por eso asusta. La clave está en la amplificación: cada byte que el atacante manda por la red se convierte en miles de bytes reservados del lado del servidor, y esa memoria queda tomada indefinidamente.
El resultado, según el análisis original de Calif, es que una sola conexión desde una PC hogareña con 100 Mbps alcanza para dejar sin memoria a un servidor vulnerable. No hace falta una botnet ni una campaña coordinada: es asimétrico a favor del atacante. Según el reporte, más de 880.000 servidores públicos aparecían expuestos en escaneos de Shodan al momento de la divulgación.
¿Cómo funciona el exploit por dentro?
El HTTP/2 Bomb encadena dos técnicas viejas y conocidas por separado, pero que juntas se potencian. La combinación es lo nuevo, y es exactamente el tipo de patrón que un humano tiende a pasar por alto y una IA que compara codebases enteros detecta.
- La bomba (HPACK Indexed Reference Bomb): HTTP/2 comprime las cabeceras con HPACK, que mantiene una "tabla dinámica" de cabeceras ya vistas. El atacante siembra una cabecera y después la referencia miles de veces con índices de 1 byte. Cada byte en el cable dispara entre 70 y 4.000 bytes de memoria reservada del lado del servidor.
- El freno (Window Stall): el cliente anuncia una ventana de control de flujo de cero bytes, así el servidor nunca termina de enviar la respuesta ni libera lo que reservó. Cada tanto manda un
WINDOW_UPDATEde 1 byte para resetear los timeouts y evitar que la conexión se cierre. - El truco final: el ataque explota el overhead de bookkeeping por cada entrada —la contabilidad interna del servidor—, no el tamaño de la cabecera ya decodificada. Por eso esquiva los límites clásicos de tamaño de header. Además, en Apache y Envoy se aprovecha del field splitting del header
Cookieque permite el RFC 9113.
¿A qué servidores afecta y qué tan grave es?
La gravedad varía muchísimo según la implementación. Estos son los números que reportó la investigación para las versiones probadas (la amplificación es la relación bytes reservados por byte enviado):
| Servidor (versión probada) | Amplificación | Memoria | Tiempo |
|---|---|---|---|
| Envoy 1.37.2 | ~5.700:1 | ~32 GB | ~10 s |
| Apache httpd 2.4.67 | ~4.000:1 | ~32 GB | ~18 s |
| Nginx 1.29.7 | ~70:1 | ~32 GB | ~45 s |
| Microsoft IIS (Server 2025) | ~68:1 | ~64 GB | ~45 s |
Envoy y Apache son los casos más extremos por la amplificación brutal. Nginx e IIS aguantan más, pero igual caen. Cloudflare Pingora también figura entre los afectados. Verificá siempre la versión exacta que corrés contra el aviso oficial, porque los números dependen de la build. Red Hat publicó su propio boletín agrupando el problema como RHSB-2026-007 (CVE-2026-49975 y CVE-2026-47774).
¿Por qué HAProxy queda de pie?
Acá está lo interesante desde el punto de vista de arquitectura. No es que HAProxy tenga un parche mágico: es que su diseño nunca le dio lugar al ataque. Según el aviso oficial de HAProxy, "HAProxy es arquitectónicamente seguro frente a este exploit gracias a sus estrictas restricciones de memoria" y "no necesitás cambiar nada para que HAProxy sobreviva a este ataque".
La diferencia de fondo:
- Memoria acotada por diseño: mientras los servidores vulnerables usan tracking dinámico de memoria para los streams multiplexados, HAProxy maneja los streams de HTTP/2 con límites de memoria fijos y presupuestados de antemano. No hay una tabla que crezca sin techo.
- Procesamiento a nivel bare-metal: procesa los frames de HTTP/2 sin acumular estado costoso por cada entrada, que es justo lo que el exploit necesita para amplificar.
- Mitigaciones opcionales extra: para quienes quieran endurecer todavía más, HAProxy 3.4+ ofrece
tune.h2.fe.max-rst-at-onceytune.h2.fe.glitches-threshold(por ejemplo, en 200) para cortar conexiones que superen cierto umbral de anomalías, más stick-tables para rechazar clientes sospechosos antes de que hagan daño.
La lección no es "usá HAProxy y listo", sino algo más profundo: los límites duros y previsibles de recursos son una defensa estructural, no un parche reactivo. Un componente que se niega a reservar memoria sin techo es inmune a toda una familia de ataques de agotamiento, no solo a este.
¿Qué podés hacer hoy en tu Cloud Server?
Si administrás un servidor propio, el plan de acción es concreto y no requiere esperar a nadie:
- Actualizá Nginx a 1.29.8 o superior. Esa versión introdujo la directiva
max_headers(por defecto 1000), que pone un techo a la cantidad de cabeceras por request. Es la mitigación oficial. - Actualizá Apache httpd a una versión con
mod_http2v2.0.41 o superior, donde los "crumbs" de cookies pasan a contar contraLimitRequestFields, cerrando el vector del field splitting. - Aplicá el Patch Tuesday de junio 2026 en IIS. Microsoft abordó la vulnerabilidad en esa tanda de actualizaciones; mantené Windows Server al día.
- Si no podés parchear ya, desactivá HTTP/2 en el servidor afectado (IIS, Envoy o Pingora sin parche). Volver temporalmente a HTTP/1.1 elimina la superficie de ataque mientras preparás la actualización.
- Considerá poner HAProxy adelante como reverse proxy que termina HTTP/2 antes de tus backends. Absorbe el tráfico malicioso con sus límites fijos y protege lo que tenés detrás.
- Revisá tu exposición real: confirmá qué servicios tuyos hablan HTTP/2 de cara a internet. Un proxy interno que solo usa HTTP/1.1 no está en riesgo por este CVE en particular.
Si venís de endurecer tu stack —por ejemplo si ya seguiste una guía de asegurar Nginx con Let's Encrypt o evaluaste el fork Angie de nginx—, este es un buen momento para sumar el chequeo de versión y HTTP/2 a esa misma rutina de mantenimiento.
Preguntas frecuentes
¿Necesito ancho de banda enorme para sufrir este ataque?
No. Justamente eso es lo que lo hace peligroso: una sola conexión desde una conexión residencial común alcanza, porque la amplificación hace el trabajo pesado del lado del servidor.
¿HAProxy necesita un parche para este CVE?
No. Según su aviso oficial, HAProxy sobrevive al ataque por su arquitectura de memoria acotada sin cambios de configuración. Las directivas de tuning son un endurecimiento opcional, no un fix obligatorio.
¿Alcanza con desactivar HTTP/2 como solución definitiva?
Es una mitigación válida y rápida, pero no es la solución ideal a largo plazo porque perdés los beneficios de rendimiento de HTTP/2. Usala como puente hasta poder aplicar el parche correspondiente.
¿Cómo descubrió la vulnerabilidad un modelo de IA?
El modelo Codex de OpenAI analizó código público y detectó que dos técnicas conocidas por separado —una bomba de compresión HPACK y un freno estilo Slowloris con ventana cero— se potenciaban al combinarse. Es un patrón difícil de ver para un revisor humano y un buen ejemplo de IA aplicada a análisis de seguridad.
¿Dónde confirmo si mi versión está afectada?
Chequeá el boletín del proyecto que usás y el seguimiento del CVE-2026-49975 contra la versión exacta que corrés. No asumas: verificá con nginx -v, apachectl -v o el build de tu proxy antes de dar por seguro tu servidor.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
