Cómo manejar la vulnerabilidad HTTP/2 Bomb: impacto y mitigación de CVE-2026-49975

Thu, 11 Jun 2026 08:43:45 +0800

HTTP/2 Bomb es un riesgo de denegación de servicio en HTTP/2 divulgado recientemente. Está relacionado con CVE-2026-49975, y el problema central es que un atacante puede enviar solicitudes pequeñas que hacen que el servidor asigne y mantenga grandes cantidades de memoria, hasta ralentizar el servicio, empujarlo a swap o dejarlo inaccesible.

Es fácil confundirlo con “otro DDoS más”. Pero el peligro no está en un gran volumen de tráfico, sino en la amplificación de memoria: el cliente envía pocos datos, mientras el servidor puede pagar un coste de recursos mucho mayor al procesar compresión de cabeceras HTTP/2 y estado de control de flujo.

Para equipos de operaciones y seguridad, lo más importante ahora no es reproducir el ataque. Es identificar dónde termina HTTP/2 y después actualizar los componentes relevantes o desactivar HTTP/2 temporalmente.

Dónde está el peligro

HTTP/2 Bomb combina dos clases de problemas antiguos.

La primera es la amplificación relacionada con HPACK. HTTP/2 usa HPACK para comprimir cabeceras. Un cliente puede usar referencias muy cortas que obligan al servidor a reconstruir y asignar estructuras de cabecera. Si una implementación no limita bien el número de campos de cabecera, fragmentos de Cookie o el coste interno de bookkeeping, el servidor puede asignar mucha memoria para una entrada muy pequeña.

La segunda es una retención similar a Slowloris. El atacante puede usar el control de flujo de HTTP/2 para impedir que el servidor complete normalmente su respuesta, manteniendo durante mucho tiempo en el proceso la memoria asignada previamente.

Por separado, ninguna de estas ideas es nueva. Lo problemático es que, al encadenarlas, el ataque no necesita mucho ancho de banda ni necesariamente una gran cantidad de conexiones para llevar la memoria backend a un estado peligroso.

Componentes que conviene revisar primero

Las divulgaciones públicas mencionan las siguientes implementaciones de servidor HTTP/2 como afectadas o al menos relevantes para revisar:

nginx
Apache httpd
Microsoft IIS
Envoy
Cloudflare Pingora

NVD actualmente describe CVE-2026-49975 en relación con mod_http2 de Apache HTTP Server, afectando Apache HTTP Server 2.4.17 a 2.4.67. Red Hat también clasifica el problema relacionado como denegación de servicio HTTP/2 HPACK e indica que httpd, nginx, Envoy y otros componentes requieren tratamiento por separado.

Hay dos detalles importantes.

Primero, no todos los servicios backend de aplicación están expuestos directamente. Lo primero que hay que revisar son los puntos de terminación HTTP/2: balanceadores públicos, proxies inversos, Ingress, gateways, capas de origen de CDN, API Gateway y entradas de service mesh.

Segundo, la asignación de CVE y la cobertura por fabricante no coinciden exactamente en todos los productos. No asumas que un único número CVE cubre todos los componentes que usas. Revisa cada componente HTTP/2 real contra el aviso de su proveedor o distribución.

Autorrevisión rápida

Empieza en este orden:

¿Tus entradas públicas tienen HTTP/2 activado?
¿Dónde termina HTTP/2: CDN, WAF, balanceador, Nginx, Apache, Envoy, IIS o service mesh?
¿La versión del componente que termina HTTP/2 está dentro del rango corregido por el fabricante?
¿Hay un proxy superior capaz de limitar cantidad de campos de cabecera, fragmentos de Cookie, vida de conexión y memoria por worker?
¿Existe alguna ruta que evite CDN/WAF y conecte directamente con el origen?

Muchos sitios parecen estar detrás de CDN, pero IPs de origen, dominios de respaldo, dominios de prueba, entradas de administración o entradas canary todavía pueden exponer HTTP/2 directamente. Lo que hay que revisar son todos los bordes que pueden aceptar HTTP/2, no solo el dominio principal.

Correcciones y mitigaciones

La prioridad más alta es actualizar.

Si usas nginx, las divulgaciones públicas mencionan que 1.29.8+ introdujo límites relevantes. Si no puedes actualizar, considera desactivar HTTP/2 temporalmente.

Si usas Apache httpd, revisa la versión corregida de mod_http2. Fuentes públicas mencionan mod_http2 v2.0.41 como versión con corrección. La mitigación temporal indicada por Red Hat es forzar que los virtual hosts afectados usen solo HTTP/1.1:

`1`	`Protocols http/1.1`

Si usas nginx y necesitas una mitigación temporal, puedes desactivar HTTP/2 según la guía del fabricante o distribución, por ejemplo:

`1`	`http2 off;`

Si usas Envoy, IIS, Pingora o gateways gestionados, sigue el aviso correspondiente del proveedor. No apliques sin más la lógica de configuración de Nginx o Apache, porque el punto vulnerable y la forma de corrección pueden ser distintos.

Para sistemas que no pueden actualizarse de inmediato, considera estas medidas defensivas:

Limitar en el borde el número de campos de cabecera por solicitud, incluidos campos cookie divididos;
Limitar streams HTTP/2 con vida anormalmente larga;
Definir límites de conexiones HTTP/2, streams concurrentes, tasa de solicitudes y memoria;
Establecer límites razonables de memoria para workers o contenedores, evitando que un proceso arrastre al host completo;
Permitir que el origen solo reciba tráfico de proxies confiables, evitando bypass de WAF/CDN;
Monitorizar número de conexiones HTTP/2, streams activos, picos de memoria, uso de swap y errores 5xx.

Estas medidas no sustituyen los parches, pero reducen la exposición durante la ventana de corrección.

Escenarios de mayor riesgo

El riesgo suele ser mayor en estos entornos:

Nginx / Apache / Envoy / IIS expuestos públicamente con HTTP/2 activado;
API Gateway o capas Ingress con HTTP/2 activado;
Orígenes accesibles directamente evitando CDN;
Hosts con poca memoria que alojan varios sitios o servicios;
Sin límites de memoria para workers o contenedores;
Sin monitorización de conexiones, streams y memoria anómalos;
Servicios sensibles a disponibilidad sin plan rápido de retorno a HTTP/1.1.

Aunque tu servicio sea solo interno, no conviene ignorarlo por completo. Ataques internos, uso accidental de scripts de prueba, exposición de componentes de cadena de suministro o errores de configuración en service mesh pueden convertir un problema público en un problema interno de disponibilidad.

No mires solo CVSS

La puntuación de este tipo de vulnerabilidad puede resultar confusa. Algunas fuentes destacan CVSS 9.8, mientras que la página de NVD muestra actualmente un CVSS 3.1 de CISA-ADP de 7.5 High, y la valoración propia de NVD sigue en proceso de enriquecimiento.

Para la defensa real, la puntuación no debería ser el primer criterio. Las preguntas más útiles son:

¿Tu entrada HTTP/2 está afectada?
¿Es accesible desde Internet?
¿Ya actualizaste a una versión corregida por el fabricante?
¿Puedes desactivar HTTP/2 rápidamente?
¿Tienes protecciones de memoria, conexión y stream?
¿Existe una ruta que evite las defensas frontales y llegue al origen?

Si varias respuestas son inciertas, trátalo como prioridad alta.

Orden recomendado para operaciones

Puedes avanzar en este orden:

Enumerar todos los puntos de terminación HTTP/2;
Comparar versiones y estado de corrección con avisos de fabricantes;
Actualizar primero entradas públicas y proxies de borde;
Desactivar HTTP/2 temporalmente donde aún no sea posible actualizar;
Verificar que el origen solo acepte tráfico de proxies confiables;
Definir límites de memoria para workers, contenedores o procesos de servicio;
Añadir monitorización para conexiones HTTP/2, streams, cantidad de campos de cabecera y anomalías de memoria;
Tras la ventana de cambio, verificar que el tráfico de negocio sigue funcionando normalmente.

Desactivar HTTP/2 puede afectar rendimiento, reutilización de conexiones y experiencia de algunos clientes. Pero cuando no hay parche o la exposición no está clara, es una opción temporal más estable que dejar el borde desprotegido.

Conclusión

El punto clave de HTTP/2 Bomb no es “cuánto tráfico” envía el atacante, sino que una solicitud pequeña puede provocar grandes asignaciones de memoria y mantenerlas retenidas. Esto lo hace especialmente peligroso para servicios de borde con HTTP/2 activado por defecto.

No empieces intentando reproducirlo ni dependas de una sola página CVE. Primero identifica todos los puntos de terminación HTTP/2 y luego confirma el estado componente por componente: Nginx, Apache, Envoy, IIS, Pingora o tu distribución. Actualiza cuando sea posible. Si no puedes actualizar, desactiva HTTP/2 temporalmente y añade límites de campos de cabecera, conexiones, streams y memoria en el borde.

Referencias: divulgación original de Calif, NVD CVE-2026-49975, análisis de HAProxy, Red Hat RHSB-2026-007

Apache on KnightLi Blog