Apache HTTP Server HTTP/2 RCE, corregido en 2.4.71 (CVE-2026-119618)

Resumen

• El módulo mod_http2 de Apache HTTP Server escribe un encabezado Content-Length sintético en una tabla compartida con el hilo de conexión. Apache califica el fallo como crítico. Red Hat le asigna una puntuación CVSS v3.1 de 9.8.
• Las versiones 2.4.55 a 2.4.70 están afectadas cuando HTTP/2 está activado con h2 o h2c. Los servidores que solo hablan HTTP/1.1 no están afectados.
• Red Hat afirma que una investigación pública demostró un exploit fiable contra un servidor configurado por defecto. No se enlaza código de exploit público y no se conoce explotación real; el CVE no está en el catálogo KEV de CISA al 2026-11-12.
• Actualice a 2.4.71 o al paquete corregido de su distribución. Si no puede, desactive HTTP/2; consulte «¿Cómo lo corrijo?».

¿Estoy afectado?

Está expuesto si se cumplen todas estas condiciones:

• Ejecuta Apache HTTP Server 2.4.55 a 2.4.70.
• mod_http2 está cargado y HTTP/2 está activado, mediante Protocols h2 http/1.1 para TLS o h2c para texto claro.
• Los clientes no confiables pueden alcanzar ese listener HTTP/2, directamente o a través de un proxy que reenvía HTTP/2 a Apache.

Los servidores configurados solo para HTTP/1.1 no están afectados. Red Hat indica que RHEL 8 y versiones anteriores no están afectados porque su mod_http2 es anterior a la versión 2.0.8.

RHEL 9 y RHEL 10 están afectados, pero se clasifican como Important. Red Hat explica que cada flujo HTTP/2 se asigna desde un asignador distinto, lo que aumenta considerablemente la complejidad de la explotación. El aviso de Apache enumera mod_h2 2.0.8 a 2.0.42 como afectado; la versión 2.4.71 incluye el módulo corregido.

Apache lo utiliza el 20.9% de los sitios web cuyo servidor web se conoce, según W3Techs. El rango afectado es un subconjunto de esos despliegues, porque HTTP/2 debe estar activado.

Compruebe la versión instalada y si HTTP/2 está activo:

# Debian and Ubuntu
apache2 -v
apache2ctl -M | grep http2

# RHEL, Fedora and other RPM distributions
httpd -v
httpd -M | grep http2

# The Protocols directive shows whether h2 or h2c is enabled
grep -R "Protocols" /etc/apache2 /etc/httpd 2>/dev/null

Para un contenedor, compruebe el proceso en ejecución y no una imagen recién descargada:

docker exec <container> apache2 -v
docker exec <container> apache2ctl -M | grep http2

En RHEL, httpd -v sigue mostrando la versión base 2.4 después de la corrección. La actualización de seguridad cambia el paquete mod_http2, así que compare ese paquete con el aviso:

rpm -q mod_http2

RHEL 9.9 incluye mod_http2-2.0.26-7.el9_9.1, según la página CVE de Red Hat. RHEL 10.3 incluye mod_http2-2.0.29-5.el10_3.1. Las compilaciones anteriores de mod_http2 en esas ramas están afectadas.

¿Cómo lo corrijo?

Actualice a Apache HTTP Server 2.4.71 o instale el paquete mod_http2 corregido que publique su distribución. Red Hat publicó los retroportes el 2026-11-11. El DSA-6620-1 de Debian incluye apache2 2.4.71 para Debian 13.

1. Actualice el paquete: ```bash # Debian and Ubuntu sudo apt update sudo apt install --only-upgrade apache2

# RHEL and Fedora sudo dnf update httpd mod_http2 2. Confirme la compilación corregida. En Debian 13, `apache2 -v` muestra 2.4.71. Las versiones anteriores de Debian y Ubuntu reciben la corrección aplicada a su serie actual, así que compare la versión que muestra `dpkg -s apache2` con la del DSA o USN de su versión. En RHEL, compare `rpm -q mod_http2` con la versión del paquete que indica el aviso. 3. Reinicie Apache para cargar el módulo nuevo:bash sudo systemctl restart apache2 # Debian and Ubuntu sudo systemctl restart httpd # RHEL and Fedora ``` 4. Reconstruya y recree cada imagen de contenedor que incluya Apache. Descargar una imagen nueva no basta si el contenedor en ejecución sigue usando la capa anterior.

Si compila desde el código fuente, use el archivo de la versión 2.4.71 del proyecto Apache HTTP Server.

Si no puede actualizar de inmediato, desactive HTTP/2. El fallo está en la ruta de solicitud HTTP/2, así que eliminar esa ruta lo cierra. El coste es perder el beneficio de rendimiento del multiplexado.

1. En Debian y Ubuntu, desactive el módulo y reinicie: bash sudo a2dismod http2 sudo systemctl restart apache2
2. En RHEL y Fedora, comente la línea LoadModule http2_module y asegúrese de que Protocols no incluye h2 ni h2c, y después reinicie: bash sudo systemctl restart httpd
3. En cualquier distribución, confirme que el módulo ya no aparece con apache2ctl -M | grep http2 o httpd -M | grep http2. Si no hay salida, HTTP/2 está desactivado.

Un proxy inverso que termina HTTP/2 y reenvía HTTP/1.1 a Apache elimina esta ruta en el backend. El proxy puede seguir afectado si ejecuta una compilación vulnerable de Apache. Desactivar HTTP/2 es una solución temporal, no una corrección; el módulo corregido es la respuesta duradera.

¿Cuál es la causa raíz?

mod_http2 traduce las tramas HTTP/2 a una estructura request_rec interna, y assign_headers() copia los encabezados de solicitud analizados en la tabla de encabezados de la solicitud. El fallo es que una rama escribe un encabezado Content-Length sintético en la tabla de origen compartida en lugar de la copia propia de la solicitud.

La función está en modules/http2/h2_request.c. Este es el código en la etiqueta 2.4.70:

static void assign_headers(request_rec *r, const h2_request *req,
                           int no_body, int is_connect)
{
    const char *cl;

    r->headers_in = apr_table_clone(r->pool, req->headers);

    if (req->authority && !is_connect) {
        ...
        apr_table_setn(r->headers_in, "Host", req->authority);
    }

    /* Unless we open a byte stream via CONNECT, apply content-length guards. */
    if (!is_connect) {
        cl = apr_table_get(req->headers, "Content-Length");
        if (no_body) {
            if (!cl && apr_table_get(req->headers, "Content-Type")) {
                /* If we have a content-type, but already seen eos, no more
                 * data will come. Signal a zero content length explicitly.
                 */
                apr_table_setn(req->headers, "Content-Length", "0");
            }
        }

req->headers es la tabla de encabezados analizada para el flujo en la conexión. r->headers_in es un clon asignado en el grupo de memoria de la solicitud, y es la tabla que leen los módulos de Apache. La función recibe req como const h2_request *, por lo que no debería modificarlo. La rama Host de este fragmento escribe en r->headers_in, lo que muestra el destino previsto. La rama Content-Length es la excepción.

El desencadenante es estrecho y no necesita cuerpo. no_body es verdadero cuando el cliente pone END_STREAM en la trama HEADERS, así que no sigue ningún cuerpo de solicitud. Si esa solicitud tiene un Content-Type y ningún Content-Length, la rama se ejecuta.

apr_table_setn() añade una clave nueva, lo que agranda la tabla y asigna memoria en el grupo de la tabla. Ese grupo pertenece a la conexión y al flujo, mientras que la escritura se ejecuta en el hilo de trabajo del flujo. Red Hat describe el resultado como un hilo de trabajo que escribe en memoria del hilo de conexión a través de un asignador compartido y sin bloqueo.

Las tablas y los grupos de memoria de APR no son seguros entre hilos. Por eso, una asignación o un recorrido concurrente de la misma tabla puede corromper el montón. El aviso clasifica el fallo como un problema de ejecución concurrente con sincronización incorrecta (CWE-362), y la descripción de Apache nombra directamente assign_headers().

¿Cómo se explota?

1. El atacante abre una conexión HTTP/2 con el servidor, por TLS con h2 o en texto claro con h2c.
2. El atacante envía muchas solicitudes HEADERS concurrentes por esa conexión. Cada solicitud lleva :method, :path, :authority y un Content-Type, y establece END_STREAM sin Content-Length.
3. Cada solicitud llega a assign_headers() en un hilo de trabajo con no_body activo. El hilo añade Content-Length: 0 a la tabla req->headers compartida.
4. Mientras el hilo asigna memoria en esa tabla, el hilo de conexión y otros hilos pueden leer o asignar en la misma tabla y el mismo grupo. La carrera corrompe el montón.
5. Apache indica que la corrupción puede llevar a la ejecución remota de código. Un fallo del hilo o del proceso del servidor es el resultado más simple.

El aviso no publica código de exploit. Red Hat afirma que una investigación pública demostró un exploit fiable contra un servidor configurado por defecto con mod_http2 activado, y por eso califica el fallo como crítico. No se conoce explotación real al 2026-11-12.

¿Cómo se desarrolla el ataque?

Un cliente HTTP/2 no autenticado envía una solicitud sin cuerpo que lleva un Content-Type pero ningún Content-Length, y la escritura sintética del hilo de trabajo compite con el asignador del hilo de conexión hasta corromper el montón.

flowchart LR
    A["Cliente HTTP/2<br/>HEADERS + END_STREAM"] --> B["mod_http2 activa<br/>no_body"]
    B --> C["assign_headers()<br/>Content-Type, sin Content-Length"]
    C --> D["apr_table_setn(req->headers)<br/>tabla compartida, hilo de trabajo"]
    D --> E["asignador compartido<br/>del hilo de conexión"]
    E --> F["corrupción del montón"]
    F --> G["fallo o ejecución<br/>remota de código"]

¿Qué puede hacer un atacante?

Un atacante no autenticado que puede alcanzar un listener HTTP/2 puede provocar un fallo del servidor. Si la corrupción del montón se convierte en una primitiva útil, puede ejecutar código como el usuario que ejecuta Apache. El aviso de Apache indica que el fallo puede llevar a la ejecución remota de código. Red Hat va más lejos y afirma que una explotación correcta permite comandos arbitrarios, el control total del proceso del servidor y el acceso a datos sensibles.

Red Hat califica el fallo con CVSS v3.1 9.8, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Las condiciones son las de «¿Estoy afectado?»: una versión 2.4 afectada, mod_http2 cargado, HTTP/2 activado y accesibilidad de red. El atacante no necesita cuenta ni interacción del usuario.

La explotación depende de ganar una carrera, así que su fiabilidad varía con la carga, la distribución del asignador y el número de flujos concurrentes. Red Hat clasifica RHEL 9 y RHEL 10 como Important en lugar de Critical por ese motivo, aunque los sigue enumerando como afectados.

Un fallo es una denegación de servicio, no una ejecución de código. Las fuentes describen la ejecución de código como posible y, según Red Hat, demostrada en investigación. Ninguna fuente publica un exploit funcional ni un informe de víctima.

¿Por qué funciona la corrección?

El parche cambia una línea de assign_headers() para que el encabezado sintético vaya al clon propio de la solicitud:

@@ -350,7 +350,7 @@ static void assign_headers(request_rec *r, const h2_request *req,
                 /* If we have a content-type, but already seen eos, no more
                  * data will come. Signal a zero content length explicitly.
                  */
-                apr_table_setn(req->headers, "Content-Length", "0");
+                apr_table_setn(r->headers_in, "Content-Length", "0");
             }
         }

r->headers_in se asigna en el grupo de memoria de la solicitud y solo lo usa el hilo que atiende este flujo. La tabla req->headers compartida ya no se modifica después de crear el clon, así que el hilo de trabajo deja de escribir en la memoria del hilo de conexión. El encabezado sintético sigue llegando a los módulos posteriores, porque leen r->headers_in.

El cambio cubre la única escritura en req->headers de assign_headers(). La otra escritura de encabezado de la misma función, para Host, ya usaba r->headers_in. La corrección no cambia el framing HTTP/2 ni el tratamiento del cuerpo de la solicitud.

¿Cómo compruebo si estuve comprometido?

No se publican indicadores de compromiso para este fallo. Una explotación correcta puede no dejar rastro más allá de la memoria corrompida, y un intento fallido puede limitarse a provocar un fallo de un hilo.

Busque fallos y salidas inesperadas de procesos hijos en el registro de errores de Apache, sobre todo en servidores que exponían HTTP/2 antes de la corrección:

grep -Ei "segfault|signal 11|child pid .* exit|AH00051" /var/log/apache2/error.log
grep -Ei "segfault|signal 11|child pid .* exit|AH00051" /var/log/httpd/error_log

En un host con systemd, enumere los volcados de memoria del binario de Apache:

coredumpctl list apache2
coredumpctl list httpd

Un fallo es una pista, no una prueba de explotación, porque otros errores y límites de recursos también pueden matar un hilo. Si encuentra fallos repetidos en un servidor HTTP/2 que ejecutaba una compilación afectada, conserve los registros y los volcados antes de reiniciar. Trate el host como posiblemente comprometido hasta que lo haya revisado.

Cronología

• 2026-10-26: el OSS Scanner de Anthropic informa del fallo al equipo de seguridad de Apache como ANT-2026-MAPKT6MZ.
• 2026-11-03: Anthony Weems y Simon Scannell, de Google Cloud Vulnerability Research, informan del fallo de forma independiente.
• 2026-11-09: la corrección llega a la rama 2.4.x con el commit 824beab, un cherry-pick del commit 5ed3928 de master.
• 2026-11-11: Apache publica 2.4.71 y el aviso CVE-2026-119618. Red Hat publica el mismo día sus paquetes mod_http2 corregidos y sus avisos.

Preguntas frecuentes

¿Afecta a los servidores que solo usan HTTP/1.1?

No. El fallo está en la ruta de solicitud HTTP/2. Un servidor que carga mod_http2 pero solo negocia HTTP/1.1 no llega a assign_headers().

Mi proxy inverso termina TLS. ¿Está expuesto mi backend Apache?

Depende del protocolo entre el proxy y Apache. Si el proxy reenvía HTTP/2, el backend está expuesto. Si reenvía HTTP/1.1, esta ruta está cerrada en el backend, pero el proxy puede ejecutar una compilación afectada de Apache.

¿Existe un exploit público?

No se enlaza código de exploit público desde el aviso de Apache ni desde el registro CVE. Red Hat afirma que una investigación pública demostró un exploit fiable contra un servidor configurado por defecto con mod_http2 activado.

¿Está CVE-2026-119618 en el catálogo KEV de CISA?

No. El CVE no estaba en el catálogo Known Exploited Vulnerabilities de CISA al 2026-11-12, y no se conoce explotación real.

¿Qué versiones de RHEL están afectadas?

RHEL 9 y RHEL 10 están afectados y se clasifican como Important. RHEL 8 y versiones anteriores no están afectados porque su mod_http2 es anterior a 2.0.8. Instale la versión del paquete mod_http2 que indica el aviso de Red Hat para su rama.

¿Por qué httpd -v sigue mostrando 2.4.57 después de la actualización de RHEL?

Red Hat retroportó la corrección al paquete mod_http2 en lugar de cambiar la versión de httpd. Compare rpm -q mod_http2 con la versión corregida del paquete, no con la cadena de versión de httpd.

Referencias

• Página de seguridad de Apache HTTP Server, aviso CVE-2026-119618, publicado el 2026-11-11: https://httpd.apache.org/security/vulnerabilities_24.html (consultado el 12 de noviembre de 2026)
• Registro CVE-2026-119618, CNA Apache Software Foundation, publicado el 2026-11-11: https://www.cve.org/CVERecord?id=CVE-2026-119618 (consultado el 12 de noviembre de 2026)
• Commit de la corrección en la rama 2.4.x, 824beab, 2026-11-09: https://github.com/apache/httpd/commit/824beab9b9424d6cfb29595248fdbf6c3dddeab1 (consultado el 12 de noviembre de 2026)
• Commit de la corrección upstream en master, 5ed3928, 2026-11-09: https://github.com/apache/httpd/commit/5ed39287660daacd1233cb9bbc984b25fa9a4fe3 (consultado el 12 de noviembre de 2026)
• Página CVE-2026-119618 de Red Hat, CVSS v3.1 9.8 y paquetes mod_http2 corregidos, publicada el 2026-11-11: https://access.redhat.com/security/cve/CVE-2026-119618 (consultado el 12 de noviembre de 2026)
• Seguimiento de seguridad de Debian para CVE-2026-119618, DSA-6620-1 y apache2 2.4.71 corregido: https://security-tracker.debian.org/tracker/CVE-2026-119618 (consultado el 12 de noviembre de 2026)
• W3Techs, cuota de uso de Apache, 20.9% de los sitios cuyo servidor web se conoce: https://w3techs.com/technologies/details/ws-apache (consultado el 12 de noviembre de 2026)