Apache corrige un RCE en mod_http2 que descubrió la IA de Anthropic

El 26 de octubre de 2026, el escáner de inteligencia artificial de Anthropic avisó al equipo de seguridad de Apache de un fallo en mod_http2, y el 11 de noviembre salió el parche en Apache HTTP Server 2.4.71. CVE-2026-119618 permite a un atacante sin credenciales corromper la memoria de cualquier servidor que sirva HTTP/2, Red Hat lo puntúa con un 9,8 y, antes de que pasaran veinticuatro horas desde el aviso, ya había en GitHub un repositorio que dice reproducirlo.

La captura del aviso de Apache recoge las tres entradas de la versión 2.4.71 y, en la primera, las dos fechas que marcan el caso, el informe de Anthropic del 26 de octubre y el de Google del 3 de noviembre.

Una línea en h2_request.c separa Apache 2.4.70 de 2.4.71

Apache titula el fallo «mod_http2: heap corruption and RCE in assign_headers» (corrupción de memoria dinámica y RCE en assign_headers) y lo clasifica como CWE-362, ejecución concurrente sobre un recurso compartido sin la sincronización debida. La función assign_headers() de mod_http2 construye la petición interna a partir de las cabeceras que llegan en un flujo HTTP/2. Cuando la petición trae un tipo de contenido pero el cliente ya ha señalado el final del flujo, el módulo añade por su cuenta una cabecera Content-Length con valor cero.

El commit 824beab9, que Apache cita como corrección en la rama 2.4.x, cambia exactamente una línea de modules/http2/h2_request.c. Esa cabecera deja de escribirse en la tabla req->headers, la que comparte la petición HTTP/2, y pasa a escribirse en r->headers_in, la tabla propia de cada petición. El cambio llegó a trunk el 9 de noviembre en la pull request 975, abierta y fusionada el mismo día por el desarrollador covener sin una sola línea de descripción, dos días antes de que el aviso le pusiera nombre.

La captura del commit en GitHub muestra el diff completo, una línea borrada y otra añadida en la función assign_headers. Red Hat, que ha analizado el fallo para sus propios paquetes, lo describe con algo más de detalle en su ficha, donde afirma que «a worker thread writes into memory owned by the connection thread» (un hilo de trabajo escribe en memoria que pertenece al hilo de la conexión) a través de un asignador compartido sin bloqueo. HTTP/2 multiplexa muchas peticiones sobre una sola conexión y mod_http2 las reparte entre hilos. Si dos de ellos tocan la misma tabla de cabeceras a la vez, el montón se corrompe y, con el tráfico adecuado, esa corrupción se convierte en ejecución de código con los privilegios del proceso httpd.

Solo están expuestos los servidores que negocian h2 o h2c mediante la directiva Protocols. Un Apache que solo sirve HTTP/1.1 no entra en el aviso de Red Hat, aunque tenga mod_http2 cargado, siempre que Protocols no incluya h2 ni h2c.

Un escáner de IA el 26 de octubre y dos investigadores de Google el 3 de noviembre

Apache atribuye el hallazgo a dos fuentes independientes. La primera es OSS Scanner, el servicio de Anthropic que registró el fallo como ANT-2026-MAPKT6MZ y lo comunicó al equipo de seguridad el 26 de octubre. La segunda son Anthony Weems y Simon Scannell, de Google Cloud Vulnerability Research, cuyo informe llegó el 3 de noviembre. Entre el primer aviso y el parche pasaron dieciséis días.

OSS Scanner existe desde el 8 de octubre de 2026. Anthropic lo presentó como un servicio gratuito al que los mantenedores de proyectos de código abierto se apuntan mediante una pull request y que pasa sus modelos más potentes por el código de forma periódica. Cada informe incluye un reproductor, una explicación del fallo y, cuando es posible, un parche candidato. La propia empresa avisa de que los resultados son «fully model-generated, without human review or triage» (generados por completo por el modelo, sin revisión ni triaje humanos) y de que, en su validación interna, 85 de 97 hallazgos críticos o altos en 48 proyectos pasaron el listón de la divulgación coordinada.

Anthropic anunció el servicio en X el día del lanzamiento. El de Apache no es el primer fallo de calado que un modelo de la empresa pone sobre la mesa. A finales de octubre contamos cómo un exploit escrito por un modelo interno de Anthropic consiguió root remoto en el kernel Linux a través de un use-after-free en TCP.

De un 9,8 en Red Hat a sin puntuar en NVD, con una PoC en GitHub al día siguiente

La puntuación numérica la pone Red Hat, no Apache. El proyecto solo califica el fallo como crítico, sin vector CVSS, y la ficha de NVD estaba en estado Received y sin métricas a las 07:00 UTC del 12 de noviembre, con el registro publicado a las 15:17 UTC del día anterior. Red Hat le asigna un 9,8 con vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H y lo califica de crítico para el conjunto de sus productos, aunque rebaja la calificación a Important en RHEL 9 y RHEL 10 porque sus paquetes de mod_http2 asignan cada flujo HTTP/2 desde un asignador separado, lo que complica la explotación. Hay otra discrepancia menor en la clasificación, porque Apache usa CWE-362 y Red Hat, CWE-20.

Lo que más pesa de la nota de Red Hat es la frase «public research has demonstrated a reliable exploit» (la investigación pública ha demostrado un exploit fiable), referida a un servidor con la configuración por defecto y mod_http2 activo. Red Hat no enlaza ni nombra esa investigación. Wiz, en su análisis del 11 de noviembre, afirmaba lo contrario para ese momento: «no exploit is available and there are no reports of exploitation in the wild» (no hay exploit disponible ni informes de explotación activa).

Esa foto duró poco. A las 05:05 UTC del 12 de noviembre, el agregador Sploitus indexó un repositorio público de GitHub, googlesky/CVE-2026-119618, que se presenta como un laboratorio en contenedores con una PoC en Python de biblioteca estándar, evidencias de ASan y TSan y una comparación entre 2.4.70 y 2.4.71. No hemos ejecutado ese código ni podemos confirmar que haga lo que dice. Lo que sí es un hecho es que existe, que cualquiera puede descargarlo y que el fallo no está en el catálogo KEV de CISA, cuya última versión en el momento de escribir es la del 10 de noviembre. Apache HTTP Server acumula cuatro entradas en ese catálogo, la última CVE-2024-38475, incorporada el 1 de mayo de 2025.

Qué Apache está expuesto, de Debian bookworm a los clientes de Wiz en la nube

El rango afectado va de 2.4.55 a 2.4.70 y alcanza también a quien compile mod_h2 por su cuenta desde GitHub, entre las versiones 2.0.8 y 2.0.42. Red Hat añade un dato útil para descartar máquinas. Las versiones de mod_http2 anteriores a 2.0.8 no contienen el código vulnerable, así que RHEL 8 y anteriores no están afectados. Sí lo están JBoss Core Services y las Hardened Images de Red Hat, para las que el fabricante no listaba corrección a las 07:00 UTC del 12 de noviembre.

El rastreador de seguridad de Debian, en la captura, deja la foto de las distribuciones. Bookworm sirve 2.4.67-1~deb12u3 desde su repositorio de seguridad, trixie 2.4.69-1~deb13u1 y forky 2.4.69-1, y las tres figuran como vulnerables. Solo sid tiene 2.4.71-1. Ubuntu no tenía página para el CVE a esa hora. Red Hat sí publicó el mismo 11 de noviembre sus erratas, mod_http2-2.0.26-7.el9_9.1 para RHEL 9 (RHSA-2026:98981) y mod_http2-2.0.29-5.el10_3.1 para RHEL 10 (RHSA-2026:98978), además de las ramas de soporte extendido 9.4, 9.6, 9.8, 10.0 y 10.2.

Nadie ha publicado todavía un recuento de servidores Apache con HTTP/2 a la vista desde Internet, ni Shodan ni Shadowserver ni Censys, en el momento de escribir esta noticia. Las únicas cifras de exposición son las de Wiz sobre su base de clientes. El 64 % de los entornos en la nube que monitoriza tiene recursos con una versión afectada y el 51 % los tiene expuestos públicamente, sin tener en cuenta si HTTP/2 está activo. Para dimensionar el parque, W3Techs atribuye a Apache el 20,9 % de los sitios web cuyo servidor conoce, con datos del 12 de noviembre de 2026.

INCIBE-CERT, por su parte, no tenía aviso sobre 2.4.71 a esa misma hora. Sus últimos avisos son del 11 de noviembre y cubren Ivanti, Confluence, SAP, Microsoft, N-central y Fortinet. El precedente más cercano es INCIBE-2026-696, del 2 de octubre, que acompañó a la versión 2.4.69 con tres fallos críticos, entre ellos otro use-after-free en mod_http2.

Subir a 2.4.71 hoy o dejar Protocols en http/1.1 hasta poder hacerlo

Lo primero es averiguar qué versión corre cada servidor y si negocia HTTP/2. Estos comandos lo resuelven en RHEL y derivados. En Debian y Ubuntu el binario se llama apache2 y la configuración vive en /etc/apache2.

httpd -v
httpd -M 2>/dev/null | grep -i http2
grep -RiE "^\s*Protocols\s" /etc/httpd/ /etc/apache2/ 2>/dev/null
rpm -q mod_http2 2>/dev/null; dpkg -l apache2-bin 2>/dev/null | tail -1

Desde fuera, una petición con curl dice si el servidor acepta h2. Si imprime 2, negocia HTTP/2 y entra en el rango de riesgo.

curl -sI --http2 -o /dev/null -w '%{http_version}\n' https://tu-servidor.example/

Con esa información, el orden de trabajo queda así.

1. Actualiza a Apache HTTP Server 2.4.71 en los servidores que negocian h2 o h2c y están publicados en Internet, empezando por los que sirven aplicaciones con sesión o datos de usuarios. Si compilas mod_h2 aparte, pasa a una versión posterior a 2.0.42 en cuanto exista o vuelve al módulo que trae 2.4.71.
2. En RHEL 9 y RHEL 10 instala las erratas RHSA-2026:98981 y RHSA-2026:98978 (mod_http2 2.0.26-7.el9_9.1 y 2.0.29-5.el10_3.1) y reinicia httpd. La de RHEL 9 cierra también CVE-2026-57941.
3. Si no puedes actualizar hoy, retira h2 y h2c de la directiva Protocols, en el servidor y en cada VirtualHost que la redefina, y recarga la configuración.
4. Revisa los contenedores y appliances que empaquetan httpd, que heredan la versión del binario y hay que reconstruirlos o esperar la imagen del proveedor.
5. En Debian bookworm y trixie, y en Ubuntu, vigila el rastreador de seguridad y los USN, porque a las 07:00 UTC del 12 de noviembre no había paquete corregido en stable. Mientras tanto aplica la mitigación de Protocols.
6. Si ves caídas repetidas de procesos hijo de httpd con HTTP/2 activo, trátalas como posible intento de explotación, conserva los core dumps y los registros del servidor y notifícalo a INCIBE-CERT si eres empresa o al CCN-CERT si eres administración pública.

Wiz propone este ajuste para quien no pueda parchear de inmediato, y deja el servidor solo con HTTP/1.1.

Protocols http/1.1

Tres fallos de memoria en mod_http2 en seis meses, la lectura del blog

CVE-2026-119618 es el tercer fallo de memoria en el código HTTP/2 de Apache desde mayo. El 4 de mayo de 2026, la versión 2.4.67 cerró CVE-2026-23918, un double free en el reinicio temprano de flujos que Apache tituló «http2: double free and possible RCE on early reset» (double free y posible RCE en el reinicio temprano) y que afectaba a 2.4.66. El 1 de octubre, 2.4.69 corrigió CVE-2026-57941, un use-after-free por reentrada en el búfer compartido session->bbtmp que arrastraban las versiones desde 2.4.17. Apache lo calificó de moderado e INCIBE-CERT, de crítico. Y el 11 de noviembre llega el de assign_headers, el único de los tres al que el propio proyecto llama crítico.

El patrón que vemos es el de un módulo que reparte el trabajo de una conexión entre varios hilos y arrastra tablas y asignadores compartidos de su diseño original. Que la corrección sea una línea no dice nada sobre la gravedad. Dice que el fallo era fácil de corregir una vez localizado, no de encontrar. Que lo encontrara primero un escáner automático y lo confirmaran después dos investigadores humanos en una semana apunta a que esta clase de fallos, los de concurrencia en código C veterano, es justo la que un modelo con tiempo de máquina ilimitado va a seguir sacando a la luz. La cadena de suministro del software libre ya vivió algo parecido con Brotli hace tres semanas, con un fallo que saltó de un proyecto a otro conforme se revisaban las copias.

La parte incómoda para los administradores de Apache en producción es la ventana. La pull request con el cambio estuvo pública en trunk desde el 9 de noviembre, el aviso llegó el 11 y la PoC, el 12. Cualquiera que siguiera los commits de mod_http2 tenía dos días de ventaja sobre el aviso, y esa es la ventana que vimos con WordPress 7.1.4 y con PHP2Shell hace unas semanas, cuando el tiempo entre parche público y sondeos se contó en horas. Si tu Apache sirve h2 y no puedes actualizar esta semana, retira HTTP/2 hoy, porque la pérdida de rendimiento se nota menos que un proceso httpd ejecutando órdenes de otro.