- Microsoft corrige más de 1000 fallos y debes actualizar cuanto antes Windows
- Un fallo crítico sin parche afecta al plugin Confection de WordPress
Apache ha publicado la versión 2.4.71, lanzada ayer, para corregir un fallo crítico en mod_http2, el módulo que gestiona el tráfico HTTP/2 en su servidor web. El problema, registrado como CVE-2026-119618, permite a un atacante remoto ejecutar código en el servidor sin necesidad de autenticarse, siempre que el protocolo esté activo. Red Hat le otorga una puntuación de 9,8 sobre 10 en la escala CVSS.
El fallo está presente en la función assign_headers(), dentro de ese mismo módulo. Se trata de un problema de concurrencia: dos partes del código acceden a la misma zona de memoria sin el bloqueo adecuado, lo que puede corromper el heap y derivar en ejecución remota de código. El CVE sigue marcado como reservado, sin puntuación CVSS oficial de Apache ni análisis técnico público todavía.
Red Hat, que distribuye el servidor en Red Hat Enterprise Linux, señala que basta con alcanzar el servidor por red: no hace falta credencial alguna, y quien lo consiga controla por completo el proceso. Solo quedan expuestos los servidores con HTTP/2 activado.
Las versiones de Apache en riesgo y qué más corrige la 2.4.71
La vulnerabilidad afecta a Apache HTTP Server desde la versión 2.4.55 hasta la 2.4.70, y queda resuelta en la 2.4.71, publicada el 11 de noviembre de 2026. La misma actualización corrige otros dos fallos menores: CVE-2026-106023, calificado de importante, un puntero nulo en mod_md que puede tumbar un proceso hijo al atender una petición y que afecta a las versiones 2.4.30 a 2.4.70; y CVE-2026-109163, de severidad baja, una sobreescritura de un byte en la pila de mod_vhost_alias, limitada a las versiones 2.4.69 y 2.4.70.
Quien compiló el módulo de forma independiente desde el repositorio mod_h2 en GitHub debe revisar sus propias versiones: el fallo cubre de la 2.0.8 a la 2.0.42. Ahí no hay parche disponible, porque el repositorio se archivó el 9 de junio y quedó en modo de solo lectura. La única protección pasa por aplicar la mitigación de la directiva Protocols que te explicamos más abajo.
Cómo saber si tu servidor tiene HTTP/2 activado
HTTP/2 solo se activa cuando la directiva Protocols lo indica, con los valores h2 para HTTP/2 sobre TLS o h2c para HTTP/2 sobre TCP sin cifrar. Vamos a explicarte qué debes revisar: esa directiva puede fijarse para todo el servidor o solo para un host virtual, así que debes comprobar tanto la configuración global como cada host virtual antes de dar el servidor por seguro, incluso si ya actualizaste el principal.
Red Hat ya ha publicado parches para Red Hat Enterprise Linux 9 y 10; en RHEL 9, por ejemplo, el paquete corregido es mod_http2-2.0.26-7.el9_9.1. Ahí la compañía rebaja la severidad a Important en lugar de Critical, porque sus paquetes reservan un asignador de memoria propio para cada flujo HTTP/2, lo que complica el ataque. RHEL 8 y versiones anteriores no incluyen el código vulnerable. Debian y Amazon Linux ya reflejan sus propios parches en sus rastreadores de seguridad, y el de Ubuntu no tenía todavía página abierta para este CVE cuando se consultó.
Sin parche alternativo: cómo reducir el riesgo mientras actualizas
Apache no ha publicado ninguna solución alternativa en su aviso de seguridad, así que la 2.4.71 es el único remedio definitivo. Si no puedes aplicarla ya, te recomendamos seguir la indicación de la firma de seguridad Wiz: retira h2 y h2c de la directiva Protocols y deja solo Protocols http/1.1, tanto en la configuración global como en cada host virtual. Pruébalo antes en un entorno de pruebas, porque afecta al rendimiento y a algunos clientes, y vigila los registros por si aparecen caídas o reinicios extraños de los procesos worker.
Sobre la disponibilidad real de un exploit hay versiones contrapuestas entre Red Hat y la firma de seguridad Wiz. Red Hat asegura en su evaluación que «la investigación pública ha demostrado un exploit fiable» contra una configuración por defecto con mod_http2 activo, aunque no identifica esa investigación. Wiz, ese mismo día, sostuvo lo contrario: que no existía ningún exploit disponible ni se había reportado explotación activa. El escáner de código abierto de Anthropic detectó el fallo el 26 de octubre; Anthony Weems y Simon Scannell, de Google Cloud Vulnerability Research, lo reportaron por su cuenta el 3 de noviembre.
La 2.4.71 llega un mes después de que la 2.4.69 cerrase 20 CVEs en octubre, y de que la 2.4.68 resolviera otros 13 en junio, mes en que el ataque HTTP/2 Bomb golpeó las configuraciones por defecto de varios servidores populares, Apache incluido. El fallo anterior en este protocolo, CVE-2026-23918, se cerró el 4 de mayo con la versión 2.4.67: quien actualizó entonces, o después hasta la 2.4.70, sigue necesitando este segundo parche.