La nueva vulnerabilidad de bomba HTTP/2 permite DoS remoto en NGINX, Apache, IIS, Envoy y Cloudflare
Los investigadores de ciberseguridad han descubierto un exploit de denegación de servicio remoto que afecta a los principales servidores web, incluidos NGINX, Apache HTTPD, Microsoft IIS, Envoy y Cloudflare Pingora.
La vulnerabilidad ha sido nombrada en código. Bomba HTTP/2 por California.
«El comportamiento vulnerable existe en la configuración HTTP/2 predeterminada de cada servidor», dijo la compañía, y agregó que fue descubierto por OpenAI Codex encadenando dos técnicas conocidas: una bomba de compresión y una retención estilo Slowloris.
«La bomba apunta a HPACK, el esquema de compresión de encabezados de HTTP/2: un byte en el cable se convierte en una asignación de encabezado completa en el servidor, que se repite miles de veces por solicitud», agregó Calif. «La retención es una ventana de control de flujo de cero bytes que evita que el servidor libere nada».
HPACK es un algoritmo de compresión de encabezados dedicado para HTTP/2 que se utiliza para comprimir metadatos de solicitudes y respuestas utilizando la codificación Huffman que da como resultado una reducción promedio del 30 % en el tamaño del encabezado. También está diseñado para ser resistente a ataques como DELITO (abreviatura de «Compression Ratio Info-leak Made Easy») que puede filtrar cookies de autenticación de encabezados comprimidos.
Slowloris, por otro lado, es un tipo de ataque de denegación de servicio (DoS) que permite a un actor de amenazas abrumar un servidor objetivo abriendo y manteniendo muchas conexiones HTTP simultáneas entre el atacante y el objetivo. Es un ataque a la capa de aplicación.
HTTP/2 Bomb está inspirado en varios enfoques conocidos como HPACK Bomb (también conocido como CVE-2016-6581), que se reveló por primera vez en 2016, así como CVE-2025-53020una vulnerabilidad de agotamiento de la memoria en la implementación HTTP/2 de Apache httpd y dos fallas DoS en el servidor Apache HTTP a través de marcos de CONTINUACIÓN diseñados (CVE-2016-8740) y hambre de hilo de trabajo (CVE-2016-1546) en una conexión HTTP/2.
«Lo nuevo aquí es de dónde viene la amplificación», dijo Calif. «La bomba clásica introduce un valor grande en la tabla y hace referencia a él repetidamente, por lo que los servidores aprendieron a limitar el tamaño total del encabezado decodificado. Nuestra variante va en sentido contrario: el encabezado está casi vacío y la amplificación proviene de la contabilidad por entrada que el servidor asigna a su alrededor. El límite de tamaño decodificado nunca se activa porque no hay casi nada que decodificar».
En un escenario de ataque hipotético, una computadora doméstica con una conexión de 100 Mbps tiene el potencial de hacer que un servidor vulnerable sea inaccesible en cuestión de segundos. Es más, un solo cliente puede consumir y retener 32 GB de memoria del servidor contra Apache HTTPD y Envoy en aproximadamente 20 segundos.
Para contrarrestar la vulnerabilidad, se recomienda aplicar las siguientes mitigaciones:
- NGINX: actualice a 1.29.8+, que agrega la directiva max_headers con un valor predeterminado de 1000. Si la actualización no es una opción, se recomienda deshabilitar HTTP/2 con http2 desactivado.
- Apache HTTPD – Corregido en mod_http2 v2.0.41. Si la actualización no es una opción, se recomienda configurar los protocolos http/1.1 para deshabilitar HTTP/2.
- Microsoft IIS, Envoy y Cloudflare Pingora: no hay ningún parche disponible al momento de escribir este artículo.
«El error más profundo es que las especificaciones enmarcan el riesgo de memoria puramente como una relación de amplificación, y la relación es sólo la mitad de la ecuación», dijo Calif. «Un amplificador 70:1 es inofensivo si la memoria se libera cuando se completa la solicitud. Se convierte en un ataque porque HTTP/2 permite al cliente mantener la conexión abierta casi de forma gratuita, fijando cada byte asignado durante el tiempo que desee».
