Apache HTTP Server 2.4.71, publicado el 11/11/2026, corrige CVE-2026-119618, una vulnerabilidad crítica en el módulo HTTP/2 que puede permitir a un atacante remoto sin autenticar ejecutar código en el servidor. Afecta a las versiones 2.4.55 a 2.4.70 cuando HTTP/2 está activado, una configuración habitual en hosting, proxies inversos y pasarelas de aplicaciones.
Las claves del fallo CVE-2026-119618 en Apache en 20 segundos
- Afecta a Apache 2.4.55 a 2.4.70 con HTTP/2 (h2 o h2c) activado.
- Puede permitir ejecución remota de código sin autenticación; Red Hat le da un CVSS de 9,8.
- La solución es 2.4.71 o el paquete corregido de la distribución.
- Mientras tanto, se puede limitar Protocols a http/1.1.
El fallo es una condición de carrera en la función assign_headers() de mod_http2: peticiones HTTP/2 concurrentes pueden corromper la memoria del proceso. Lo descubrieron de forma independiente la herramienta OSS Scanner de Anthropic y dos investigadores de Google Cloud Vulnerability Research. Red Hat asegura que una investigación pública ha demostrado un exploit fiable contra configuraciones por defecto, aunque no la identifica, mientras que Wiz no tenía constancia de exploits disponibles ni de ataques. En OpenSecurity hemos publicado el análisis técnico completo de CVE-2026-119618, con los comandos para comprobar la exposición.
Por qué importa en entornos de hosting y nube
Apache HTTP Server sigue siendo una pieza central en muchos servicios de alojamiento, paneles de control, balanceadores y backends detrás de proxies. HTTP/2 se activa a menudo por rendimiento y luego se olvida, y el rango afectado es amplio: la 2.4.55 salió en enero de 2023. Además, quien actualizó en mayo a 2.4.67 para cerrar otro fallo grave de HTTP/2, CVE-2026-23918, sigue expuesto a este.
En plataformas con imágenes de contenedor o plantillas de máquinas virtuales, el riesgo está en las copias que no se reconstruyen: actualizar el paquete en los servidores vivos no corrige las imágenes base de las que saldrán los siguientes despliegues. También hay que revisar dónde termina la conexión HTTP/2: si un balanceador o una CDN la terminan y hablan HTTP/1.1 con Apache, el backend no es alcanzable por esta vía, pero si el HTTP/2 llega hasta Apache, sí.
Estado de los parches por distribución
Red Hat ya ha publicado paquetes corregidos de mod_http2 para RHEL 9 y 10, y aclara que RHEL 6, 7 y 8 no están afectados; en sus sistemas califica el fallo de «importante» porque su compilación asigna memoria por flujo HTTP/2, lo que complica la explotación. Debian tenía el arreglo en sid y el resto de versiones estaban en proceso, Amazon Linux lo tenía pendiente y Ubuntu no había publicado aviso cuando se publicó la vulnerabilidad. En Ubuntu 22.04 y 24.04 el paquete incluye un mod_http2 retroportado, así que el número de versión de Apache no basta para descartar el riesgo.
El mod_h2 independiente de GitHub (2.0.8 a 2.0.42) también está afectado y no tendrá parche, porque el repositorio está archivado desde junio. La versión 2.4.71 corrige, además, un cierre inesperado en mod_md y una sobrescritura de un byte en mod_vhost_alias.
Si no se puede actualizar de inmediato, Wiz recomienda dejar la directiva Protocols en http/1.1, tanto en la configuración global como en cada virtual host que la redefina, o desactivar mod_http2. Supone renunciar temporalmente a HTTP/2, pero elimina la superficie de ataque.
Preguntas frecuentes
¿Qué versiones de Apache están afectadas?
Apache HTTP Server 2.4.55 a 2.4.70 con HTTP/2 activado, y el mod_h2 independiente 2.0.8 a 2.0.42.
¿Me afecta si uso un balanceador o una CDN delante?
Depende de si el tráfico HTTP/2 llega hasta Apache. Si el balanceador termina HTTP/2 y habla HTTP/1.1 con el backend, el fallo no es alcanzable por esa vía.
¿Qué hago si no puedo actualizar todavía?
Limitar la directiva Protocols a http/1.1 o desactivar mod_http2 hasta poder instalar 2.4.71 o el paquete corregido.
Fuentes:
