Un portátil, unos segundos y 32 GB de memoria consumida: hallan una vulnerabilidad en el protocolo que sustenta la mitad de Interne

Los investigadores de Calif encontraron la vulnerabilidad HTTP/2 Bomb, que permite sobrecargar remotamente la memoria de servidores web populares y dejar el servicio fuera de servicio rápidamente. El problema afecta a las configuraciones predeterminadas de HTTP/2 en nginx, Apache httpd, Microsoft IIS, Envoy y Cloudflare Pingora. Para el ataque no se requiere una botnet grande: según los investigadores, un ordenador doméstico normal con una conexión de 100 Mbit/s puede dejar un servidor vulnerable inaccesible en cuestión de segundos.

HTTP/2 Bomb combina dos técnicas conocidas: la bomba de compresión y el mantenimiento de la conexión al estilo Slowloris. Por separado, ambas técnicas son bien conocidas por los desarrolladores de servidores y los especialistas en protección de infraestructuras. El esquema nuevo es peligroso por la combinación: primero se obliga al servidor a asignar memoria para procesar multitud de encabezados, y luego el cliente mantiene la conexión abierta y no permite liberar los recursos.

La parte de compresión del ataque se dirige a HPACK, el algoritmo de compresión de encabezados en HTTP/2. Los encabezados transmiten datos de control de la petición y la respuesta: la dirección, las cookies, el tipo de contenido, los parámetros de caché y otros campos. Sin compresión, los metadatos ocuparían demasiado espacio, especialmente con un gran número de peticiones similares. HPACK resuelve esto mediante una tabla dinámica: un extremo de la conexión añade un encabezado una vez y luego puede referirse a él con un índice corto, a veces de solo un byte.

En funcionamiento normal, el mecanismo ahorra tráfico y reduce la sobrecarga. En HTTP/2 Bomb el ahorro se convierte en un amplificador de carga. El atacante introduce de antemano un encabezado en la tabla dinámica y luego envía miles de referencias de índice cortas. Un byte en el paquete de red obliga al servidor a crear una estructura completa de encabezado en la memoria. Repetir la operación miles de veces en una sola petición genera una brecha pronunciada entre el coste para el atacante y el consumo de memoria en el lado del servidor.

La parte del ataque que recuerda a Slowloris usa el control de flujo en HTTP/2. El protocolo permite al receptor anunciar el tamaño de la ventana, es decir, informar al emisor cuántos bytes se pueden transmitir a continuación. En HTTP/2 Bomb el cliente fija una ventana de control de flujo de cero para la respuesta del servidor. El servidor no puede completar la transmisión de la respuesta, por lo que no cierra el flujo y no libera la memoria ya asignada para procesar los encabezados.

Para que la conexión no caduque por timeout, el atacante envía periódicamente pequeños marcos WINDOW_UPDATE. El servidor ve actividad y continúa manteniendo vivo el flujo, pero en realidad no puede completar correctamente el procesamiento de la petición. Como resultado, la memoria permanece asociada al flujo bloqueado durante el tiempo que permitan los tiempos de espera y la configuración de la implementación concreta de HTTP/2.

Los investigadores subrayan que los elementos individuales del ataque no parecen nuevos. HPACK Bomb ya se discutía en 2016 en el contexto de CVE-2016-6581. En Apache httpd previamente se encontraron problemas similares de agotamiento de memoria en HTTP/2, incluyendo CVE-2025-53020. Vulnerabilidades de DoS parecidas surgieron por marcos CONTINUATION especialmente elaborados y por el agotamiento de los hilos de trabajo en conexiones HTTP/2. HTTP/2 Bomb se distingue por la fuente de amplificación de la carga.

La bomba de compresión clásica suele colocar en la tabla un valor grande y referirse a él repetidamente. Los servidores aprendieron a limitar el tamaño total de los encabezados descomprimidos, por eso un simple aumento del valor suele topar con ese límite. En el esquema nuevo el encabezado está casi vacío. La carga no surge por el tamaño de los datos descomprimidos, sino por las estructuras de servicio que el servidor crea alrededor de cada entrada. El límite del tamaño de los encabezados decodificados no entra en juego porque casi no hay nada que decodificar.

Para los servidores que limitan el número de campos de encabezado, los investigadores encontraron una forma de eludirlo mediante las cookies. La especificación HTTP/2 permite dividir el encabezado Cookie en varios campos separados para mejorar la eficiencia de la compresión. Apache httpd y Envoy, en la configuración probada, no contaban los fragmentos de cookie como campos ordinarios al contabilizar el límite. El efecto posterior dependía de cómo el servidor reunía de nuevo las cookies antes de entregar la petición a la aplicación.

Envoy añade cada fragmento de cookie en un búfer. Con un valor grande de cookie al que se hace referencia decenas de miles de veces, la amplificación lógica alcanza aproximadamente 3600:1, y el consumo de memoria medido, incluyendo la sobrecarga, aumenta aún más. En la demostración de Calif con Envoy 1.37.2, el factor de amplificación fue de alrededor de 5700:1 y el consumo de memoria subió hasta unos 32 GB en 10 segundos.

Apache httpd se comporta de manera distinta y recompone la cadena cookie combinada al añadir cada fragmento. Las copias antiguas permanecen en memoria hasta que se limpia el flujo, por lo que incluso una cookie vacía puede dar una amplificación de alrededor de 4000:1. En la demostración Apache httpd 2.4.67 consumió unos 32 GB de memoria en aproximadamente 18 segundos.

nginx y Microsoft IIS mostraron un factor de amplificación menor, pero el problema aun así conduce a una denegación de servicio. En las pruebas de Calif, nginx 1.29.7 presentó alrededor de 70:1 y alcanzó aproximadamente 32 GB de memoria en 45 segundos. Microsoft IIS en Windows Server 2025 mostró alrededor de 68:1 y cerca de 64 GB de memoria en el mismo intervalo. Para atacar un servidor real, al atacante no le hace falta llevar el proceso al fallo catastrófico. Una táctica más rentable es mantener la carga algo por debajo del umbral de fallo del proceso, forzar el sistema a usar swap y ralentizar drásticamente el procesamiento de las demás peticiones.

HTTP/2 Bomb fue descubierto por OpenAI Codex durante el análisis de bases de código de servidores. Según Calif, el modelo unió dos ideas conocidas desde hace tiempo en una cadena de trabajo y ayudó a construir una variante combinada del ataque. Los investigadores señalan por separado que tras la publicación de commits que corrigen, el camino desde el archivo diff hasta un exploit funcional se vuelve muy corto: las herramientas de IA modernas ya son capaces de reconstruir la lógica del ataque a partir de los cambios en el código.

Calif divulgó el problema de nginx en abril. Los desarrolladores de nginx añadieron la directiva max_headers y publicaron la versión 1.29.8 al día siguiente. La directiva limita por defecto el número de encabezados a 1000. Si no es posible actualizar el servidor rápidamente, los investigadores recomiendan desactivar HTTP/2 con la directiva http2 off;.

Apache recibió la notificación el 27 de mayo. La corrección llegó a mod_http2 v2.0.41: los fragmentos de cookie ahora se tienen en cuenta al comprobar LimitRequestFields. El parche está disponible en un lanzamiento independiente de mod_http2 y en la rama principal de httpd, pero en el momento de la publicación Calif aún no formaba parte de la versión estable de Apache httpd 2.4.x. Si no es posible actualizar, la protección temporal consiste en desactivar HTTP/2 mediante Protocols http/1.1.

Reducir LimitRequestFieldSize en Apache puede disminuir el daño dentro de un solo flujo, porque limita el tamaño de la cookie combinada y el número de sus fragmentos. Ese paso no cierra el problema por completo: el atacante puede repartir la carga entre varios flujos y conexiones. Disminuir LimitRequestFields no ayuda contra este esquema si el servidor no cuenta los fragmentos repetidos de cookie como campos separados.

Para Microsoft IIS, Envoy y Cloudflare Pingora, en el momento de la publicación Calif no tenía correcciones disponibles. En esas configuraciones, los investigadores aconsejan desactivar HTTP/2 donde sea aceptable o colocar delante del servidor vulnerable un componente que limite estrictamente el número de encabezados en la petición. La protección debe tener en cuenta el tamaño total de los encabezados decodificados y el número de campos, incluyendo los fragmentos de cookie por separado.

La regla general para los puntos de terminación de HTTP/2 es sencilla: el límite del tamaño de los encabezados y el límite del número de encabezados resuelven problemas distintos. El servidor necesita ambas restricciones. Además, la infraestructura debe limitar la vida útil de un flujo colgado, incluso si el cliente envía periódicamente WINDOW_UPDATE y formalmente mantiene la actividad de la conexión.

Si actualizar o desactivar HTTP/2 no es posible, Calif aconseja limitar la memoria de los procesos worker mediante cgroups, ulimit -v o límites de contenedores. Ese enfoque no elimina la vulnerabilidad, pero cambia el modo de fallo. Es mejor terminar rápidamente un worker sobrecargado y lanzar un proceso nuevo que permitir al atacante retener casi toda la memoria del servidor y ralentizar las demás peticiones.

El principal fallo no está relacionado con una implementación concreta, sino con la forma en que la especificación describe el riesgo de agotamiento de memoria. HPACK contempla el peligro de amplificación a través de la tabla dinámica y propone limitar su tamaño mediante SETTINGS_HEADER_TABLE_SIZE. HTTP/2 Bomb muestra otro camino: incluso un coeficiente de amplificación moderado se vuelve peligroso si el cliente mantiene la conexión abierta casi gratis y asigna cada byte de memoria a un flujo no finalizado.