Si administras servidores web con HTTP/2 habilitado, tienes deberes para esta semana: revisar versiones y aplicar parche. Ha aparecido un ataque de denegación de servicio bautizado como HTTP/2 Bomb, registrado como CVE-2026-49975 en el ecosistema de Apache httpd, que es capaz de dejar inservible un servidor en cuestión de segundos disparando el consumo de RAM hasta agotar la memoria del proceso.
Qué es y por qué HTTP/2 es el vector ideal
El concepto de «bomba» en seguridad —zip bomb, XML bomb, gzip bomb— describe un patrón donde una entrada pequeña genera un consumo de recursos desproporcionado en el receptor. HTTP/2 introduce características como header compression (HPACK), stream multiplexing y gestión de ventanas de control de flujo que, si no se implementan con límites estrictos, pueden convertirse en palanca para exactamente este tipo de amplificación de memoria.
En el caso del HTTP/2 Bomb, el atacante envía peticiones diseñadas para forzar al servidor a reservar y mantener bloques de RAM de forma acumulativa. Sin necesidad de ancho de banda elevado ni de una botnet masiva, el servidor agota su memoria hasta que el proceso cae o queda irresponsivo. El impacto es inmediato y la recuperación requiere reinicio del servicio: downtime real en producción.
A quién afecta
El CVE apunta al ecosistema de Apache httpd con mod_http2, pero la mitigación publicada incluye también nginx 1.29.8, lo que confirma que el vector afecta a implementaciones en múltiples stacks. Si expones servicios con HTTP/2 activo —prácticamente cualquier servidor web moderno en configuración por defecto— estás en el radio de impacto.
Esto incluye setups habituales de homelab y self-hosting: nginx como reverse proxy delante de Nextcloud, Immich, Jellyfin, Gitea o cualquier servicio interno expuesto con TLS+HTTP/2. No hace falta ser un objetivo de alto perfil; los escáneres automatizados lanzarán este tipo de sonda contra todo lo que sea accesible públicamente.
Qué hacer ahora
Las mitigaciones están disponibles. El plan de acción es directo:
- nginx: actualizar a 1.29.8 o superior. Comprueba tu versión con
nginx -v. Si usas el repositorio oficial de nginx.org el paquete ya debería estar disponible; si dependes de los repos de tu distro, verifica el estado del backport. - Apache httpd con mod_http2: actualizar a mod_http2 2.0.41. En RHEL/AlmaLinux/Rocky puedes comprobar el módulo activo con
httpd -M | grep http2. En Debian/Ubuntu revisa si el mantenedor ha incorporado el fix; si no, considera el workaround temporal. - Si no puedes actualizar de inmediato: desactiva HTTP/2 temporalmente —
Protocols http/1.1en Apache, o eliminahttp2del bloquelistenen nginx. HTTP/1.1 sigue siendo perfectamente funcional para la inmensa mayoría de cargas y elimina el vector mientras preparas el parche. - Revisa también tus límites de
http2_max_concurrent_streamsy directivas equivalentes. Reducirlos no sustituye al parche, pero reduce la superficie de ataque mientras esperas la ventana de mantenimiento.
Priorización real
Los ataques DoS a capa de aplicación son más difíciles de filtrar en perímetro que un flood volumétrico clásico, precisamente porque el tráfico parece legítimo hasta que es demasiado tarde. WAFs y rate limiters por IP ayudan en capas externas, pero no eliminan el riesgo si el servidor subyacente es vulnerable. Aquí el parche es la mitigación real.
Mi recomendación: trátalo como urgente, no como crítico de emergencia. Si tienes ventana de mantenimiento esta semana, inclúyelo. Si no, priorízalo en la primera oportunidad y activa el kill-switch de HTTP/2 en los sistemas expuestos mientras tanto.
Deja una respuesta