El 11 de noviembre de 2026, la Apache Software Foundation publicó una actualización de seguridad para Apache HTTP Server que corrige una vulnerabilidad crítica identificada como CVE-2026-119618, localizada en el módulo mod_http2 y capaz de provocar corrupción de memoria con un posible desenlace de ejecución remota de código (RCE).
El fallo afecta a las versiones comprendidas entre Apache HTTP Server 2.4.55 y 2.4.70, ambas incluidas, y fue corregido en la versión 2.4.71. Su relevancia va más allá de la gravedad habitual asociada a una vulnerabilidad de ejecución de código, porque el origen no se encuentra en una funcionalidad de aplicación, un formulario vulnerable o un error de autenticación, sino en la forma en que el servidor coordina operaciones concurrentes sobre estructuras de memoria utilizadas durante el procesamiento de solicitudes HTTP/2.
La investigación resulta especialmente interesante desde el punto de vista técnico porque la corrección incorporada por Apache modifica una única línea de código en una función encargada de preparar las cabeceras de las peticiones. Ese cambio aparentemente pequeño elimina una escritura sobre una estructura compartida y la sustituye por una modificación sobre la copia local que corresponde al contexto de procesamiento.
Comprender por qué esta diferencia puede separar un comportamiento legítimo de una vulnerabilidad crítica exige examinar cómo funciona HTTP/2, cómo se distribuye el trabajo entre distintos hilos y cómo intervienen los asignadores de memoria en Apache. También obliga a distinguir entre el alcance general anunciado por el fabricante y las particularidades de las compilaciones distribuidas por cada sistema operativo.
Qué es CVE-2026-119618 y por qué se considera crítica
CVE-2026-119618 está clasificada como una condición de carrera sobre recursos compartidos, recogida en la categoría CWE-362, y afecta a la función assign_headers() del archivo modules/http2/h2_request.c. Una condición de carrera aparece cuando varias rutas de ejecución operan sobre un recurso común sin que exista una sincronización suficiente para garantizar un orden seguro de acceso. En este caso, una operación interna que debería modificar las cabeceras de una solicitud de trabajo puede terminar alterando una tabla asociada a la petición HTTP/2 original, alojada en un contexto de memoria que también utiliza el procesamiento de la conexión. Si las operaciones coinciden en circunstancias desfavorables, pueden producirse inconsistencias en la gestión del heap y abrirse la posibilidad de afectar al flujo de ejecución del proceso.
La Apache Software Foundation clasifica el problema como crítico y describe expresamente la posibilidad de RCE. Por su parte, Red Hat publica una valoración general de 9,8 en CVSS v3.1 e indica que se ha demostrado una explotación fiable contra una configuración estándar con mod_http2 habilitado.
Esto no significa que todos los servidores ejecutando una versión incluida en el intervalo vulnerable sean explotables bajo idénticas condiciones, ya que el modelo de asignación de memoria, la configuración de los protocolos y las particularidades de cada paquete pueden cambiar materialmente el riesgo. No obstante, la combinación de acceso remoto, ausencia de autenticación previa y potencial compromiso del proceso web justifica que las instalaciones expuestas a HTTP/2 se revisen con prioridad.
Cómo funciona HTTP/2 y qué papel desempeña mod_http2
HTTP/2 introdujo la multiplexación de solicitudes y respuestas sobre una misma conexión, permitiendo que diferentes flujos de comunicación avancen simultáneamente sin tener que abrir una conexión TCP independiente para cada recurso. Este modelo reduce determinadas ineficiencias de HTTP/1.1, mejora el aprovechamiento de la red y permite intercambiar múltiples mensajes de manera concurrente, aunque también requiere que el servidor mantenga información sobre la conexión global y sobre cada uno de los flujos que contiene. En Apache HTTP Server, mod_http2 proporciona la implementación necesaria para negociar el protocolo, interpretar sus tramas, administrar los flujos y conectar ese procesamiento con la infraestructura de peticiones del servidor.
La complejidad aparece cuando distintas partes del trabajo se ejecutan en hilos separados, porque algunos objetos pertenecen al contexto general de la conexión mientras otros corresponden a una solicitud concreta que está siendo procesada por un trabajador.
Las cabeceras, la información de estado y los recursos de memoria no pueden tratarse como estructuras intercambiables: cada componente necesita saber quién es el propietario de los datos, qué operaciones están permitidas sobre ellos y qué garantías existen cuando dos hilos intentan utilizarlos al mismo tiempo. En una arquitectura de este tipo, copiar las cabeceras de una petición para trabajar sobre ellas de manera independiente no constituye solamente una cuestión de diseño; también puede ser una barrera necesaria para evitar que operaciones legítimas terminen modificando memoria compartida desde un contexto inadecuado.
El fallo dentro de assign_headers(): una escritura sobre la tabla equivocada
La función assign_headers() prepara la representación de las cabeceras que posteriormente utiliza la solicitud interna de Apache. Durante este proceso intervienen, entre otros elementos, una estructura h2_request, asociada al procesamiento HTTP/2, y una estructura request_rec, utilizada por el servidor para gestionar la petición en sus fases habituales. El código crea una copia de la tabla original mediante apr_table_clone(), de manera que las modificaciones necesarias durante el procesamiento puedan realizarse sobre las cabeceras que pertenecen a la solicitud de trabajo. El error surge en una ruta específica del código destinada a establecer una longitud de contenido igual a cero cuando se cumplen determinadas condiciones relacionadas con el cierre del flujo y la presencia de cabeceras.
Antes de la corrección, esa operación utilizaba req->headers, es decir, la tabla asociada a la petición original, en lugar de aplicar la modificación sobre r->headers_in, que representa la tabla de cabeceras de la solicitud interna. Esta confusión provoca que un trabajador pueda modificar información perteneciente al contexto de la conexión, precisamente donde las garantías de acceso concurrente pueden ser diferentes.
La vulnerabilidad no depende de que un usuario proporcione directamente una instrucción ejecutable: el problema es que una secuencia de procesamiento de cabeceras, perfectamente legítima desde el punto de vista funcional, activa una operación de escritura en un recurso cuya propiedad y sincronización no se respetan adecuadamente.
Análisis del parche oficial: una sola línea con implicaciones críticas
El cambio publicado por Apache se encuentra en el commit 824beab9b9424d6cfb29595248fdbf6c3dddeab1, dentro del archivo modules/http2/h2_request.c. El diff oficial muestra que se elimina una llamada a apr_table_setn() dirigida a la tabla original y se incorpora la misma operación sobre la tabla de la solicitud interna.
La modificación conserva la intención funcional del código, que consiste en señalar explícitamente un Content-Length de cero bytes en un caso concreto, pero cambia el objeto de destino para que la escritura ocurra en la estructura de memoria adecuada.
Esta corrección ilustra un tipo de fallo especialmente delicado en software concurrente: una referencia válida desde el punto de vista del lenguaje puede seguir siendo incorrecta desde el punto de vista del ciclo de vida y de la propiedad de la memoria. Ambas estructuras contienen cabeceras y ambas pueden parecer apropiadas si se revisa la línea de manera aislada, pero solamente una corresponde al contexto en el que el trabajador debe realizar la modificación. El hecho de que la corrección sea tan breve no implica que la vulnerabilidad fuese sencilla de descubrir ni de explotar, puesto que identificar el problema requiere relacionar la ruta de procesamiento de solicitudes, la distribución del trabajo entre hilos y los mecanismos de asignación utilizados por las estructuras afectadas.
De la condición de carrera a la corrupción del heap
Apache utiliza la Apache Portable Runtime, conocida como APR, para proporcionar mecanismos de gestión de memoria y estructuras de datos reutilizables. Dentro de este modelo, los grupos de memoria o memory pools permiten asociar asignaciones al ciclo de vida de determinados objetos o contextos de ejecución.
El problema aparece cuando distintas operaciones concurrentes intervienen sobre un recurso compartido cuyos mecanismos de asignación no ofrecen por sí solos las garantías de sincronización necesarias. Una escritura realizada por el hilo equivocado puede alterar la relación esperada entre los datos, el asignador y las estructuras que otro hilo está utilizando, generando una ventana de concurrencia en la que el estado interno deja de ser consistente.
La corrupción del heap no tiene un único resultado predeterminado. Dependiendo de las circunstancias, puede manifestarse como terminaciones inesperadas, accesos inválidos, fallos intermitentes difíciles de reproducir o alteraciones de memoria que un atacante avanzado podría intentar encadenar hasta conseguir ejecución de código. Por eso es importante no confundir el hecho demostrado de que existe una ruta vulnerable con la idea de que cualquier petición HTTP/2 aislada ejecutará instrucciones arbitrarias: el resultado depende del estado del proceso, de la concurrencia alcanzada y de las propiedades de la compilación afectada. La evaluación de Red Hat añade que se ha demostrado un exploit fiable en una configuración estándar, pero la información pública de los avisos no describe una secuencia universal de explotación aplicable a cualquier despliegue.
Qué versiones y configuraciones están realmente afectadas
El aviso de Apache delimita el intervalo vulnerable a 2.4.55–2.4.70 y también identifica como afectadas las versiones 2.0.8–2.0.42 del proyecto independiente mod_h2 distribuido a través de GitHub.
El fabricante corrigió la vulnerabilidad en Apache HTTP Server 2.4.71, publicada el 11 de noviembre de 2026. Sin embargo, encontrar un número de versión incluido en el intervalo no basta para concluir que exista exposición real: también es necesario comprobar que el módulo vulnerable esté presente y que el servidor acepte conexiones HTTP/2, bien mediante h2 sobre TLS o mediante h2c sin TLS, según la configuración efectiva de la directiva Protocols.
El análisis debe abarcar todos los hosts virtuales y rutas de acceso, ya que una instancia puede ofrecer HTTP/1.1 en un dominio y HTTP/2 en otro. Además, en entornos que incorporan proxies inversos, balanceadores o redes de distribución de contenido, conviene verificar qué protocolo utiliza cada tramo de la comunicación: un navegador puede negociar HTTP/2 con un proxy mientras que el servidor de origen recibe únicamente HTTP/1.1, pero también puede ocurrir lo contrario en conexiones internas o puntos de entrada alternativos. Por tanto, observar HTTP/2 en la conexión pública no demuestra por sí mismo que mod_http2 esté recibiendo las peticiones, ni la existencia de un intermediario garantiza automáticamente que el módulo vulnerable haya quedado fuera de la superficie de ataque.
| Componente | Versiones o condición | Evaluación |
|---|---|---|
| Apache HTTP Server | 2.4.55 a 2.4.70 | Rango afectado según Apache, cuando se utiliza la ruta vulnerable de HTTP/2. |
| Apache HTTP Server | 2.4.71 | Versión que incorpora la corrección oficial. |
| mod_h2 independiente | 2.0.8 a 2.0.42 | Rango afectado identificado por Apache para el proyecto distribuido por separado. |
| Servicio solo HTTP/1.1 | Sin negociación de h2 ni h2c | No expuesto a esta ruta de vulnerabilidad, según Red Hat. |
Por qué el riesgo puede variar entre distribuciones Linux
Un detalle esencial para interpretar correctamente esta CVE es que la versión indicada por el proyecto Apache no siempre coincide con la versión efectiva de seguridad que distribuye cada sistema operativo. Los mantenedores de Debian, Red Hat y otras plataformas pueden aplicar correcciones sobre una rama anterior mediante backports, manteniendo un número de versión que a primera vista parece vulnerable.
En consecuencia, los inventarios que comparan únicamente cadenas de versión pueden generar falsos positivos o pasar por alto componentes integrados en paquetes personalizados. La comprobación rigurosa exige correlacionar el paquete instalado, la revisión del proveedor, los avisos publicados y, cuando resulte necesario, el código que realmente se ha compilado y desplegado.
Red Hat documenta además una particularidad importante: en sus paquetes de mod_http2 para Red Hat Enterprise Linux 9 y 10, cada flujo HTTP/2 utiliza un asignador separado, lo que incrementa sustancialmente la complejidad de explotar la condición de carrera descrita. Por ese motivo, aunque la evaluación general de la vulnerabilidad es crítica, la gravedad asignada a determinados paquetes de estas plataformas es Important. Red Hat también señala que RHEL 8 y versiones anteriores no incluyen el código vulnerable. Esta distinción no debe utilizarse como justificación para posponer indefinidamente la instalación de parches, sino como ejemplo de por qué el riesgo técnico real debe contextualizarse con las características concretas de la implementación y no reducirse a una puntuación única.
Impacto potencial: qué podría conseguir un atacante
La consecuencia más grave reconocida por el fabricante es la ejecución remota de código en el proceso de Apache, que puede traducirse en acceso no autorizado a la información y a los recursos disponibles para ese proceso. En una infraestructura web, los permisos de ejecución del servicio suelen incluir acceso a archivos de configuración, contenido servido, conexiones hacia aplicaciones internas, registros operativos y, en determinados escenarios, credenciales que necesitan las aplicaciones o módulos asociados.
Por tanto, una explotación satisfactoria no debería evaluarse únicamente como un incidente del servidor HTTP, sino como un posible punto de entrada hacia otros componentes que confían en él o que comparten su entorno de ejecución.
El alcance final dependería de los privilegios efectivos, del aislamiento mediante contenedores o mecanismos del sistema operativo, de la segmentación de red y de las credenciales accesibles al proceso comprometido. Conseguir ejecutar código como el usuario del servicio no implica obtener automáticamente privilegios de administrador o root, aunque una configuración excesivamente permisiva podría amplificar considerablemente el impacto. También debe considerarse la disponibilidad, puesto que una condición de carrera que provoque corrupción de memoria puede ocasionar fallos del proceso incluso cuando no se alcance la ejecución controlada de instrucciones. En la práctica, la respuesta defensiva debe contemplar tanto el compromiso de confidencialidad e integridad como la posibilidad de interrupción del servicio.
Severidad, CVSS y estado de la explotación pública
La Apache Software Foundation utiliza la categoría de gravedad crítica para CVE-2026-119618. Red Hat, por su parte, publica una puntuación general de CVSS v3.1: 9,8, asociada al vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, que refleja un escenario de ataque por red, sin privilegios ni intervención de un usuario y con impacto elevado sobre confidencialidad, integridad y disponibilidad.
Es importante atribuir esta puntuación correctamente: el aviso de Apache confirma la gravedad crítica, mientras que la puntuación numérica procede de la evaluación de Red Hat y puede coexistir con valoraciones diferentes para paquetes y plataformas concretas.
Con la información públicamente contrastada al 12 de noviembre de 2026, Red Hat afirma que se ha demostrado una explotación fiable en una configuración estándar con el módulo habilitado, pero los avisos oficiales consultados no permiten confirmar una campaña generalizada de explotación activa ni acreditar la disponibilidad de una herramienta pública de explotación universal y verificada. Estas tres cuestiones deben mantenerse separadas: que la vulnerabilidad permita RCE, que un equipo de investigación haya logrado explotarla y que existan ataques observados contra organizaciones reales son afirmaciones diferentes. La ausencia de confirmación pública de ataques en curso no reduce la necesidad de aplicar la corrección, particularmente cuando el componente afectado se encuentra expuesto a Internet.
Cómo identificar servidores que necesitan revisión
La revisión debería comenzar por un inventario de los servidores y de los servicios que incorporan Apache HTTP Server, incluyendo máquinas virtuales, servidores tradicionales, imágenes de contenedores, appliances y componentes de terceros.
A continuación, conviene consultar la versión efectiva de httpd, comprobar la presencia de http2_module y revisar la configuración de Protocols tanto a nivel global como en cada virtual host. Estos datos deben contrastarse con los avisos de seguridad del proveedor de la distribución, ya que un paquete con una versión de Apache aparentemente antigua puede haber recibido el parche mediante una actualización específica del sistema operativo.
Una primera comprobación administrativa no constituye una prueba concluyente de vulnerabilidad o de explotación: una evaluación completa necesita incluir la topología de la infraestructura, las conexiones entre proxies y orígenes, los paquetes corregidos del proveedor y las configuraciones que pueden habilitar protocolos en ámbitos específicos. También resulta razonable revisar las imágenes de contenedores y los artefactos de despliegue, porque una actualización del sistema anfitrión no modifica automáticamente una imagen que incorpora su propia instalación vulnerable de Apache. Si los servicios se gestionan mediante automatización, el resultado de la revisión debería incorporarse al inventario de activos para facilitar tanto el parcheo como la verificación posterior.
Actualización y mitigaciones recomendadas
La solución principal es instalar Apache HTTP Server 2.4.71 o un paquete del proveedor que incluya la corrección equivalente, siguiendo los procedimientos habituales de respaldo, validación de configuración y despliegue controlado. Después de actualizar, debe verificarse que los procesos en ejecución han cargado efectivamente el código corregido, ya que sustituir archivos en disco sin completar la transición del servicio puede dejar trabajadores antiguos activos durante un tiempo.
También es conveniente revisar las dependencias, las imágenes base utilizadas por contenedores y la existencia de despliegues secundarios que no estén cubiertos por el ciclo normal de actualización de la infraestructura.
Si la actualización no puede aplicarse inmediatamente, deshabilitar temporalmente HTTP/2 en los servicios afectados y permitir únicamente HTTP/1.1 puede reducir la exposición a esta ruta vulnerable, siempre que la configuración se aplique de manera efectiva en todos los puntos relevantes. En Apache, esto exige revisar la directiva Protocols y eliminar la negociación de h2 y h2c, teniendo en cuenta posibles definiciones por virtual host. Se trata de una medida temporal y no de una alternativa equivalente al parche: puede modificar el rendimiento o la compatibilidad de determinados clientes y debe comprobarse antes de desplegarse en producción. Igualmente, los controles de acceso, los privilegios mínimos y la segmentación pueden limitar el impacto de un compromiso, pero no corrigen por sí mismos el defecto de sincronización.
Otras vulnerabilidades corregidas en Apache HTTP Server 2.4.71
La publicación de Apache HTTP Server 2.4.71 también incluye correcciones para CVE-2026-106023 y CVE-2026-109163. La primera está relacionada con una desreferenciación de puntero nulo en mod_md que puede provocar la terminación de un proceso hijo durante el tratamiento de una solicitud HTTP, mientras que la segunda afecta a mod_vhost_alias y está descrita como una sobrescritura de un byte en la pila asociada a una corrección anterior.
Aunque estas vulnerabilidades tienen una clasificación de gravedad inferior a CVE-2026-119618, su presencia en la misma actualización recuerda que el mantenimiento de un servidor web no debe organizarse exclusivamente alrededor de una única noticia de seguridad, sino mediante un proceso continuado de seguimiento de avisos, revisión de dependencias y despliegue de versiones corregidas.
Cronología del descubrimiento y la divulgación
Según la información publicada por Apache, el sistema OSS Scanner de Anthropic notificó el problema al equipo de seguridad del proyecto el 26 de octubre de 2026, bajo la referencia ANT-2026-MAPKT6MZ. Posteriormente, el 3 de noviembre de 2026, los investigadores Anthony Weems y Simon Scannell, de Google Cloud Vulnerability Research, comunicaron de manera independiente el mismo hallazgo. La corrección fue incorporada a la rama de Apache HTTP Server y se publicó con la versión 2.4.71 el 11 de noviembre de 2026, fecha en la que también se difundió el aviso de seguridad que identifica formalmente a la vulnerabilidad como CVE-2026-119618.
La coincidencia de descubrimientos independientes pone de manifiesto la dificultad de investigar defectos de concurrencia dentro de software ampliamente revisado y utilizado, así como el valor de combinar análisis automatizado, inspección del código y validación técnica.
Al mismo tiempo, la divulgación del cambio exacto facilita la comprensión del fallo y permite a los responsables de infraestructura comprobar la presencia de la corrección en sus propias compilaciones, aunque también hace más urgente que las organizaciones expuestas completen sus actualizaciones. Desde una perspectiva de ingeniería segura, el caso refuerza una lección fundamental: la protección de sistemas concurrentes exige verificar no solamente que las operaciones sobre memoria sean válidas, sino que las realice el hilo correcto sobre la estructura correcta.
Conclusiones
CVE-2026-119618 es un ejemplo significativo de cómo una operación aparentemente menor dentro del procesamiento de cabeceras HTTP puede derivar en una vulnerabilidad crítica cuando rompe las reglas de propiedad y sincronización de memoria.
El fallo se encuentra en mod_http2, afecta a Apache HTTP Server 2.4.55–2.4.70 y puede provocar corrupción del heap con posibilidad de ejecución remota de código sin autenticación, mientras que la corrección publicada en 2.4.71 sustituye una escritura sobre la tabla original de cabeceras por una operación sobre la copia perteneciente a la solicitud que se está procesando. La diferencia entre ambas instrucciones es mínima desde el punto de vista sintáctico, pero decisiva desde el punto de vista de la seguridad concurrente.
Para los administradores y equipos de seguridad, la respuesta adecuada consiste en identificar las instalaciones que realmente aceptan HTTP/2, contrastar sus paquetes con los avisos específicos del fabricante y aplicar la actualización correspondiente, sin asumir que un proxy inverso o un número de versión aislado bastan para descartar el problema.
Hasta que se complete el parcheo, la desactivación controlada de HTTP/2 puede servir como mitigación temporal en los entornos donde resulte viable. Más allá del incidente inmediato, la vulnerabilidad recuerda que incluso proyectos maduros y ampliamente utilizados pueden introducir riesgos graves cuando los límites entre contexto de conexión, solicitud y trabajador no están correctamente definidos.
Referencias oficiales y documentación técnica
- Apache Software Foundation: aviso oficial de CVE-2026-119618.
- Apache HTTP Server: commit que corrige assign_headers().
- Red Hat: análisis del impacto, CVSS y particularidades de las distribuciones.
- oss-security: publicación del aviso de Apache.
- CVE Program: registro de CVE-2026-119618.
- Apache: documentación del módulo mod_http2.