Nuestro amigo Carlos Ros nos ha despertado avisado esta mañana por el canal de Telegram de Sinologic (que, si todavía no estás en él, ya estás tardando: es donde caen estas cosas antes que en ningún sitio) de una vulnerabilidad que merece un rato de atención. Se llama HTTP/2 Bomb, tiene asignado el CVE-2026-49975, y lo inquietante no es que sea nueva, sino lo poco que hace falta para usarla: según los investigadores de Calif, basta un ordenador doméstico con una conexión de 100 Mbps para dejar fuera de servicio a servidores web grandes en cuestión de segundos.
Gracias, Carlos. Vamos a desmenuzarlo.
Qué es y por qué es tan eficaz
Aquí no hay un fallo nuevo y brillante, sino algo más astuto: encadenar problemas viejos de HTTP/2 que llevan años conocidos hasta convertirlos en un ataque demoledor.
La primera parte es una bomba de compresión: HTTP/2 comprime las cabeceras (la técnica se llama HPACK), y un atacante puede mandar un mensaje minúsculo que el servidor descomprime hasta convertirlo en una estructura gigante que devora memoria. La segunda parte es una retención tipo Slowloris: el atacante anuncia una ventana de control de flujo de cero bytes, el servidor se queda esperando para responder, y esa memoria reservada no se libera. Junta las dos cosas y tienes un servidor que se queda sin memoria a toda velocidad y deja de atender a nadie. Eso es una denegación de servicio (DoS) de manual, pero con esteroides.
El detalle elegante (y peligroso) es que la amplificación no viene de una cabecera enorme, sino de la contabilidad interna que el servidor reserva alrededor de cabeceras casi vacías. Por eso los límites clásicos de «tamaño máximo a decodificar» no siempre lo frenan: casi no hay nada que decodificar.
A quién afecta (y por qué deberías mirarlo hoy)
Se estima que puede afectar a más de 880.000 sitios que usan HTTP/2 con configuración por defecto en servidores tan comunes como NGINX, Apache HTTP Server, Microsoft IIS, Envoy o Cloudflare Pingora. Si tienes algo publicado en internet, hay muchas papeletas de que estés usando uno de estos por debajo.
Cómo saber si eres vulnerable
Hazte tres preguntas rápidas: ¿Tienes servicios expuestos a internet que hablen HTTP/2? ¿Están con configuración por defecto? ¿Tu software está sin actualizar a las versiones que ya corrigen esto?
Si la respuesta a las tres es «sí» o «no lo sé», fijo que estás en el grupo de riesgo hasta confirmar lo contrario. Si últimamente notas picos bruscos de memoria y caídas o inestabilidad repentina del servicio compatibles con agotamiento de memoria seguro que ya hay alguien que lo está probando contigo. No hay indicadores de compromiso (IOC) publicados, así que vigilar el consumo de RAM de tus servicios HTTP/2 es, hoy por hoy, tu mejor radar.
Cómo comprobar en Linux si tu servidor es vulnerable
Aquí no hay un comando mágico que te diga «sí» o «no», porque el CVE-2026-49975 no es un fallo de un único paquete, sino una cadena que depende del servidor web que uses y de su versión. Lo que sí puedes hacer en cinco minutos es reunir los tres datos que importan: qué servidor tienes, qué versión corre y si HTTP/2 está activo. Con eso ya sabrás si tienes que mover ficha.
1. Identifica qué servidor web y qué versión tienes. Lánzalo según corresponda:
# NGINX nginx -v # Apache (según distribución) apache2 -v # Debian / Ubuntu httpd -v # RHEL / CentOS / Rocky / Alma / SUSE
Apunta el número exacto. La corrección de la bomba de compresión (HPACK) llegó a Apache en la 2.4.64, y la cadena completa del CVE-2026-49975 se cerró a finales de mayo, así que cualquier Apache por debajo de esa línea es sospechoso. NGINX publicó su corrección en abril: si llevas meses sin actualizar, asume que estás por detrás.
2. Comprueba si realmente estás sirviendo por HTTP/2. Si no tienes HTTP/2 activo, este ataque concreto no te aplica. Desde el propio servidor o desde fuera:
# Protocolo negociado contra tu web
curl -I --http2 -s https://tu-dominio.com -o /dev/null -w "%{http_version}\n"
# Directivas http2 en la configuración de NGINX
grep -R "http2" /etc/nginx/ 2>/dev/null
# Módulo http2 en Apache
apachectl -M 2>/dev/null | grep http2 # Debian/Ubuntu: a2query -m http2
Si curl te devuelve 2, estás hablando HTTP/2 de cara al mundo. Si te devuelve 1.1 y no aparece ninguna directiva http2, este vector no te afecta hoy (aunque conviene parchear igual por higiene).
3. Contrasta tu versión con la parcheada de tu distribución. Casi nadie compila a mano: usas los paquetes de tu distro, y ahí lo importante no es solo el número «de arriba», sino si el mantenedor ha incorporado el parche por detrás (backport). Mira el changelog del paquete:
# Debian / Ubuntu apt-cache policy nginx # o apache2 apt changelog nginx 2>/dev/null | grep -i -m5 "CVE-2026-49975\|CVE-2025-53020\|http2" # RHEL / Rocky / Alma rpm -q nginx httpd rpm -q --changelog httpd 2>/dev/null | grep -i -m5 "CVE-2026-49975\|http2"
Si en el changelog aparece el CVE como corregido, estás cubierto aunque el número de versión te despiste. Si no aparece nada y tu versión es anterior a las indicadas arriba, toca actualizar. La regla práctica: ante la duda, actualiza y reinicia el servicio, que es rápido y no te deja expuesto esperando a estar «seguro» de que lo estabas.
Qué hacer: parchear o mitigar
El estado de los parches, a fecha del aviso, es desigual: NGINX lo solucionó en abril. Apache sacó correcciones a finales de mayo (y es quien asignó el CVE-2026-49975). Microsoft IIS, Envoy y Cloudflare Pingora aún no tenían parche disponible en ese momento, así que ahí toca estar especialmente atento a las actualizaciones del fabricante.
El plan de acción sensato es el de siempre, sin dramatismos: localiza tus servidores HTTP/2 expuestos, comprueba versión, aplica el parche del fabricante en cuanto esté disponible (en NGINX y Apache ya lo está, así que ahí no hay excusa) y, mientras tanto, monitoriza la memoria para detectar abusos. Si gestionas algo crítico de cara a internet, esto entra en el «para hoy», no en el «ya lo miraré».
La IA nos está dando más de un dolor de cabeza a los Administradores de Sistemas
Cuesta no fijarse en el patrón: este exploit se encontró usando Codex de OpenAI, igual que Copy Fail lo destapó una IA hace nada. La ofensiva con IA ya no es el futuro, es el presente, y reduce muchísimo el tiempo entre «esto era teóricamente posible» y «esto está pasando en producción». Razón de más para no dejar los parches para mañana.
¿Lo estás viendo en tus servidores? ¿Has notado picos raros de memoria últimamente? Cuéntalo en los comentarios o en el canal de Telegram de Sinologic, que para eso están estos artículos. Y gracias otra vez a Carlos Ros por el chivatazo.
Más información: SOCPrime
Únete a la comunidad Sinologic
Crea tu cuenta gratuita y participa en las conversaciones sobre VoIP, Asterisk, Kamailio y telecomunicaciones IP.
Tu turno
A veces la mejor respuesta está en los comentarios.