Fallo HTTP/2 de Apache CVE-2026-119618: actualice a 2.4.71

¿Qué es CVE-2026-119618?

CVE-2026-119618 es una vulnerabilidad crítica en mod_http2, el módulo que gestiona el tráfico HTTP/2 en Apache HTTP Server; puede provocar corrupción del heap y ejecución remota de código ^[1].

Apache la describe como una «vulnerabilidad de ejecución concurrente con recurso compartido y sincronización indebida en mod_http2 de Apache HTTP Server, en assign_headers()» que «puede llevar a RCE» ^[1]. CIRCL, el equipo nacional de respuesta a emergencias informáticas de Luxemburgo, explica que durante el procesamiento concurrente de flujos HTTP/2, un worker puede modificar una tabla de cabeceras asignada a otro contexto de ejecución, y ese acceso inseguro a memoria compartida puede corromper el heap ^[2].

Un atacante que lo lograra podría ejecutar código con los privilegios del proceso del servidor web Apache, sin iniciar sesión ^[2][4]. Se estima que Apache HTTP Server funciona en aproximadamente uno de cada cinco sitios web, según BleepingComputer ^[4].

La corrección del proyecto original cambia una única escritura en modules/http2/h2_request.c: pasa de la tabla de cabeceras de solicitud compartida a las cabeceras de entrada propias de la solicitud actual ^[2].

¿Qué versiones de Apache están afectadas?

Está afectado Apache HTTP Server de la 2.4.55 a la 2.4.70, junto con las versiones independientes de mod_h2 de la 2.0.8 a la 2.0.42 de GitHub; la versión 2.4.71 lo corrige ^[1].

Los paquetes de las distribuciones complican la comprobación de la versión. CIRCL aconseja a las organizaciones que usan paquetes mantenidos por el distribuidor que verifiquen el backport de seguridad en lugar de fiarse solo del número de versión del proyecto original ^[2]. Red Hat, según el resumen de CIRCL, califica sus paquetes de RHEL 9 y 10 como Importante en lugar de Crítico porque su asignador de memoria dificulta la explotación, e informa de que RHEL 8 y anteriores no están afectados ^[2].

Red Hat da una puntuación CVSS v3.1 general de 9,8 (Crítica) ^[2][3]. La propia calificación de Apache es Crítica ^[1].

¿Es vulnerable mi servidor Apache?

Solo si ejecuta una compilación afectada y acepta realmente conexiones HTTP/2: Red Hat dice que los servidores configurados para servir únicamente HTTP/1.1 no son vulnerables ^[3]. CIRCL subraya que la ruta de código no es accesible por el mero hecho de que mod_http2 esté instalado o cargado ^[2].

• La directiva Protocols controla HTTP/2: «h2» lo activa sobre TLS y «h2c» en texto sin cifrar ^[2].
• El valor predeterminado del núcleo de Apache es http/1.1, y cargar mod_http2 no lo cambia por sí solo ^[2]. BleepingComputer señala que HTTP/2 está desactivado por defecto ^[4].
• Un host virtual puede definir su propia directiva Protocols, de modo que comprobar solo la configuración global puede pasar por alto un sitio con HTTP/2 activado ^[2].
• Si un proxy inverso, un balanceador de carga o una CDN termina HTTP/2 y reenvía solo HTTP/1.1 a Apache, la sesión HTTP/2 del cliente no hace por sí sola que Apache sea accesible, pero conviene verificar el protocolo en cada salto ^[2].

CIRCL sugiere revisar la versión y los módulos cargados (apachectl -v, apachectl -M), los hosts virtuales configurados (apachectl -S) y cada ajuste explícito de Protocols ^[2]. Una prueba que muestre que un punto de conexión acepta HTTP/2 no demuestra que su backend sea vulnerable, y una prueba negativa no demuestra que todos los puertos o hosts virtuales rechacen HTTP/2 ^[2].

¿Cómo compruebo si mi servidor acepta HTTP/2?

CIRCL sugiere dos comprobaciones: revisar la configuración de Apache en el propio servidor y probar después el protocolo negociado desde la red, idealmente conectando directamente con Apache y no a través de un proxy ^[2].

1. Compruebe la versión y los módulos. Ejecute apachectl -v para ver la versión y apachectl -M, filtrado por http2, para ver si el módulo está cargado ^[2].
2. Liste los hosts virtuales. apachectl -S muestra todos los hosts virtuales configurados, algo importante porque cada uno puede tener su propia línea Protocols ^[2].
3. Busque todas las directivas Protocols. CIRCL ofrece un comando grep que busca en /etc/apache2 y /etc/httpd los ajustes explícitos de Protocols, incluidas las anulaciones de hosts virtuales; las rutas varían según la distribución ^[2].
4. Pruebe sobre TLS. Una solicitud curl con la opción --http2 que muestre la versión de HTTP indica si un punto de conexión HTTPS negocia HTTP/2 ^[2].
5. Pruebe en texto sin cifrar. curl con --http2-prior-knowledge comprueba si un punto de conexión HTTP plano acepta h2c ^[2].

Interprete los resultados con cuidado. Una respuesta que indique HTTP/2 muestra que el punto de conexión probado aceptó HTTP/2, pero no confirma que su backend Apache sea vulnerable; un resultado negativo no demuestra que todas las direcciones, puertos o hosts virtuales lo rechacen ^[2]. El consejo de CIRCL es confirmar juntos la configuración efectiva de Apache y el estado de los paquetes parcheados del proveedor ^[2]. En entornos en la nube, Wiz advierte de que una instancia de Apache comprometida puede convertirse en punto de entrada para el movimiento lateral hacia microservicios cercanos o puntos de metadatos de la nube, otra razón para comprobar todas las instancias y no solo el sitio web público ^[5].

¿Cómo corrijo CVE-2026-119618?

Actualice a Apache HTTP Server 2.4.71 o posterior, o instale el paquete parcheado de su distribución, reinicie Apache y confirme que los procesos en ejecución usan la nueva compilación ^[2][1].

1. Actualice Apache. Instale la 2.4.71 o una compilación del proveedor parcheada expresamente para CVE-2026-119618 ^[2].
2. Actualice mod_h2 independiente si lo usa, según indique su proveedor; Wiz dice que hay que pasar de la 2.0.42, mientras que CIRCL advierte de que no se debe dar por hecho que exista una versión independiente más reciente sin comprobarlo ^[5][2].
3. Reinicie y verifique que los procesos en ejecución usan la compilación corregida ^[2].
4. Si todavía no puede parchear, desactive HTTP/2: establezca Protocols en http/1.1, elimine h2 y h2c de todos los hosts virtuales que lo anulen, pruebe con apachectl -t y recargue ^[2]. Esto bloquea la ruta de este fallo, pero no corrige el código ^[2].
5. Restrinja el acceso a redes de confianza como medida provisional donde no sea posible ni parchear ni cambiar el protocolo ^[2].

Los investigadores de watchTowr lo resumieron como «parchee ahora o desactive h2 hasta que pueda», informa BleepingComputer ^[4]. SecurityWeek informa de que Defiant también advirtió de que las actualizaciones de seguridad de WordPress no pueden resolver el problema porque afecta al servidor web subyacente ^[3].

¿Se está explotando CVE-2026-119618?

A fecha de la publicación de Wiz del 11 de noviembre de 2026, no había ningún exploit disponible ni informes de explotación activa ^[5]. Aun así, la situación evoluciona con rapidez.

• Red Hat dice que una investigación pública ha demostrado un exploit fiable contra un servidor con mod_http2 activado, pero su aviso no identifica la investigación ^[3]. CIRCL señala que esto, por sí solo, no establece que haya explotación activa ^[2].
• Una prueba de concepto pública en GitHub informa de que reproduce corrupción de memoria y bloqueos de Apache, pero no demuestra la ejecución remota de código ^[3].
• Los datos de Wiz muestran que el 64% de los entornos en la nube contienen recursos que ejecutan versiones afectadas y que el 51% tiene instancias expuestas públicamente; Wiz señala que esto no tiene en cuenta la configuración, por lo que no son necesariamente sistemas explotables ^[5][3].

CIRCL enumera señales que conviene investigar: bloqueos inesperados de workers, reinicios anómalos, procesos hijo sospechosos, cambios no autorizados en archivos y conexiones salientes inesperadas ^[2]. Son pistas, no indicadores de compromiso confirmados, y parchear no elimina la persistencia establecida antes de la actualización ^[2].

¿Quién descubrió el fallo HTTP/2 de Apache?

Apache atribuye el mérito al OSS Scanner de Anthropic, que notificó el fallo el 26 de octubre de 2026, y a Anthony Weems y Simon Scannell, de Google Cloud Vulnerability Research, que lo notificaron de forma independiente el 3 de noviembre ^[1].

El hallazgo de Anthropic figura con el identificador interno ANT-2026-MAPKT6MZ ^[1]. SecurityWeek describe los dos informes como descubrimientos independientes ^[3]. Es otro ejemplo de herramientas automatizadas y asistidas por IA que encuentran errores graves en software de código abierto ampliamente utilizado; AI That Finds Security Bugs: What Glasswing and New CVEs Mean for You analiza qué significa esa tendencia.

La corrección se confirmó y la 2.4.71 se publicó el 11 de noviembre, el mismo día en que Apache divulgó el problema en la lista de correo oss-security ^[1][2].

¿Qué más corrige Apache 2.4.71?

Apache HTTP Server 2.4.71 corrige tres CVE en total: una crítica, una importante y una baja ^[1].

• CVE-2026-106023 (importante): una desreferencia de puntero NULL en mod_md durante el procesamiento de solicitudes que puede bloquear un proceso hijo; afecta de la 2.4.30 a la 2.4.70 ^[1].
• CVE-2026-109163 (baja): una sobrescritura de un byte en el búfer de la pila en mod_vhost_alias, que Apache etiqueta como «posterior a CVE-2026-63292» (ese fallo anterior se corrigió en la 2.4.69); afecta a la 2.4.69 y la 2.4.70 ^[1].

La versión anterior, la 2.4.69 de octubre de 2026, corrigió 20 CVE ^[1]. Los administradores que se la saltaron también obtienen esas correcciones al pasar a la 2.4.71. Para otro fallo reciente en servidores, consulte CVE-2026-98432 Explained: The Linux TCP Flaw and How to Protect Your Servers.

¿Qué deben vigilar ahora los administradores?

Estén atentos a un exploit público de ejecución remota de código, a los backports de los proveedores para su distribución y a cualquier informe de ataques activos ^[3][5].

CIRCL recomienda inventariar las instancias con HTTP/2 activado, comprobar si cada compilación de mod_http2 está afectada y parchear sin demora los sistemas expuestos, con prioridad para los sitios web, las API, los alojamientos compartidos y los servidores Apache situados detrás de frontales que reenvían HTTP/2 ^[2]. Las organizaciones que detecten actividad sospechosa deben seguir sus procedimientos de respuesta a incidentes y ponerse en contacto con su CSIRT nacional ^[2].