Apache publicó recientemente la versión 2.4.71 de su servidor HTTP, la pieza de software que sigue sirviendo buena parte de la web abierta, y con ella cerró un fallo crítico en el módulo que atiende HTTP/2. El identificador es CVE-2026-119618 y el alcance declarado va de la 2.4.55 a la 2.4.70, casi tres años de lanzamientos. Por su parte, Red Hat puntúa el problema 9,8 sobre 10 y sostiene que un atacante puede ejecutar comandos en el servidor sin presentar credenciales, siempre que HTTP/2 esté activo.
La gravedad no viene del tipo de fallo, que es conocido, sino de la combinación de dos factores. El primero es que HTTP/2 llegó para quedarse: se activa con una directiva y casi nadie la revisa después de instalarla. El segundo es que el error aparece cuando dos peticiones coinciden en el tiempo, lo que convierte cualquier servidor con tráfico real en un banco de pruebas para quien sepa provocar esa coincidencia. Un servidor que solo habla HTTP/1.1 no está afectado, y ese detalle vale más que cualquier titular.
La otra mitad de la historia es el calendario. Red Hat, Debian y Ubuntu publicaron paquetes el 11 y el 12 de noviembre; el módulo que se distribuye aparte en GitHub sigue sin versión arreglada, y esa grieta decide quién está expuesto esta semana.
El fallo está en cómo mod_http2 reparte la memoria
El aviso oficial de Apache describe el problema como una vulnerabilidad de ejecución concurrente con sincronización incorrecta, clasificada CWE-362, dentro de la función assign_headers() del módulo mod_http2. En términos llanos: cuando varias peticiones llegan a la vez, el módulo escribe las cabeceras de respuesta en un espacio de memoria de la conexión que se reparte mediante un asignador sin bloqueo. Dos flujos pueden escribir en el mismo hueco al mismo tiempo y el stack de memoria del proceso acaba corrupto.
La corrupción del stack no es un defecto cosmético. Si el atacante controla parte del contenido que se escribe, puede colocar en esa zona los bytes que le interesen y desviar la ejecución del proceso hacia código propio. El resultado teórico es ejecución remota: el servidor deja de ser un servidor y pasa a ejecutar lo que le manden.
Apache califica el fallo de crítico y no ofrece mitigación en el texto del aviso: la recomendación es actualizar a 2.4.71, y quien no pueda todavía tiene la salida de dejar de ofrecer HTTP/2.
La causa de la exposición
La opción de HTTP/2 no se activa sola. La directiva Protocols admite el valor h2 para HTTP/2 sobre TLS y h2c para HTTP/2 sobre TCP sin cifrar, y puede fijarse a nivel global o dentro de un virtual host concreto. Un administrador que quiera saber si su máquina está expuesta debe revisar las dos ubicaciones, porque un virtual host heredado puede mantener el módulo activo aunque la configuración general ya no lo mencione.
El resto de la cadena tiene su propia trampa. El módulo que se distribuye aparte, publicado en GitHub como mod_h2, arrastra el mismo error en las versiones 2.0.8 a 2.0.42. Ese repositorio lleva archivado desde el 9 de junio de 2026 y su última entrega es justo la última vulnerable, así que quien lo use no puede esperar una release: toca migrar al módulo del proyecto o apagar HTTP/2.
| Plataforma |
Estado |
Paquete o aviso |
| Apache HTTP Server |
Corregido el 11 nov |
2.4.71 |
| RHEL 9 |
Corregido |
mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981) |
| RHEL 10 |
Corregido |
mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978) |
| Debian stable y testing |
Corregido en security |
DSA-6620-1 y DLA-4902-1, versión 2.4.71 |
| Ubuntu 20.04 a 26.10 |
Corregido |
USN-9090-1 |
| Amazon Linux 2 y 2023 |
Pendiente |
sin paquete publicado |
| mod_h2 de GitHub |
Sin parche |
última release 2.0.42, arquitectura archivada |
La tabla tiene una lectura incómoda para quien confía en la distribución. El mismo día del anuncio, Red Hat ya tenía paquetes para sus dos ramas empresariales, mientras Amazon Linux seguía sin fecha. Los repositorios de seguridad de Debian publicaron la corrección con los avisos DSA-6620-1 y DLA-4902-1, y el seguimiento de paquetes todavía marca como vulnerables las versiones base de bookworm y trixie, lo que en la práctica significa que un sistema actualizado solo por el canal normal puede quedarse atrás.
Ubuntu resolvió la papeleta con la nota de seguridad USN-9090-1, publicada el 12 de noviembre, que cubre desde la 20.04 hasta la 26.10 y deja la 2.4.68-1ubuntu6.2 en la entrega más reciente. Las versiones antiguas mantienen el arreglo detrás de Ubuntu Pro, una diferencia que importa si la instalación es de 18.04 y no tiene suscripción.
Explotación confirmada, todavía no observada
El aviso de Red Hat afirma que existe investigación pública con un exploit fiable contra un servidor por defecto con mod_http2 activo, aunque no identifica ese trabajo, no lo enlaza y no aporta detalles para reproducirlo.
El resto del ecosistema va por detrás. La empresa de seguridad Wiz sostuvo el 11 de noviembre, que no había exploit disponible y que no constaban casos de explotación en curso, y su propio recuento de exposición sirve para dimensionar el problema sin dramatizarlo: el 64% de los entornos cloud analizados tenía recursos con versiones afectadas y el 51% los tenía además expuestos a internet, cifras que no descuentan la configuración de cada servidor. La prueba de concepto publicada en GitHub reproduce corrupción de memoria y caídas del proceso, no ejecución remota de código.
El detalle que separa un aviso de una emergencia es otro. CVE-2026-119618 no figuraba en el catálogo de vulnerabilidades explotadas de CISA en la revisión del 10 de noviembre, y el recuento de los doce fallos que la agencia añadió en diez días muestra el listón que sí usa para mover a las agencias federales. Tampoco hay campañas documentadas contra este fallo, y escribirlo como si las hubiera sería inventar.
La misma release corrige otros dos problemas
Actualizar a 2.4.71 no solo cierra la ejecución remota. El paquete corrige mod_md con CVE-2026-106023, una desreferencia de puntero nulo que tumba el proceso hijo durante el tratamiento de peticiones, y mod_vhost_alias con CVE-2026-109163, una escritura de un solo byte en la pila que Apache clasifica como baja. Ninguno justifica una ventana de mantenimiento por sí mismo, pero los dos viajan en la misma descarga.
El caso de mod_vhost_alias es interesante por otro motivo: llega inmediatamente después de CVE-2026-63292, un desbordamiento del mismo módulo que se corrigió en la 2.4.69, lanzada en octubre. Dos fallos en la misma pieza en dos releases consecutivas apuntan a código con poca cobertura de pruebas, y ahí la lección no es el parche concreto sino el módulo.
Sobre la urgencia relativa conviene un dato más. La rama 2.4.x acumula 44 releases y solo en 2.4.69 se corrigieron 20 vulnerabilidades, según el historial del propio proyecto, y esas dos cifras resumen el ritmo real de una pieza que casi nadie revisa.
Ese ritmo tiene coste. Quien actualiza cada seis meses vive en deuda permanente, y este otoño la ha pagado en forma de octavo cero-día de Chrome. El caso de FreeSWITCH y Apache Juneau confirma el patrón con dos fallos graves en la misma semana.
Quitar HTTP/2 cuesta tráfico y costará mucho más
La mitigación que recomienda Wiz de momento es retirar h2 y h2c de la directiva Protocols y dejar el servidor en HTTP/1.1 hasta que se solucione el problema. Pero esto tiene un coste medible: la multiplexación de HTTP/2 desaparece, cada recurso vuelve a necesitar su propia conexión y el rendimiento en redes con latencia alta se resiente. En un servidor con miles de visitas diarias ese precio se paga en milisegundos y en ancho de banda, no en seguridad.
La alternativa, actualizar de inmediato, depende de que exista paquete para tu sistema. Ahí el mapa de esta semana deja dos huecos: Amazon Linux y mod_h2. Para el primero toca esperar o compilar; para el segundo no habrá release, porque el proyecto está archivado y su último entregable es precisamente el vulnerable.
También hay que desmontar una idea que circula en foros de administración. Un parche de WordPress no toca este fallo, porque el error vive en el servidor web y no en la aplicación; el aviso de Apache no menciona ningún CMS. Lo mismo vale para los paneles de hosting que envuelven httpd sin actualizar el binario subyacente.
El calendario manda. Cada día que un servidor con h2 activo sigue en la 2.4.70 o anterior, la distancia entre una prueba de concepto que solo tumba procesos y un exploit que ejecuta código depende de si alguien publica el segundo paso. Esa publicación no ha ocurrido todavía, y el trabajo pendiente es que no te pille con la versión vieja cuando ocurra.
