Apache HTTP Server 2.4.71 corrige CVE-2026-119618, un fallo crítico en mod_http2 que puede permitir ejecutar código a distancia sin autenticación. Afecta a las versiones 2.4.55 a 2.4.70 con HTTP/2 activado. Si tu web, tienda o intranet corre sobre Apache, pide hoy que se compruebe la versión y se actualice; si no se puede, desactiva HTTP/2.
Lo esencial
- CVE-2026-119618: una sincronización insuficiente en la función assign_headers() de mod_http2 puede corromper la memoria dinámica y permitir ejecución remota de código sin autenticar. Red Hat le asigna un CVSS de 9.8.
- Versiones afectadas: Apache HTTP Server 2.4.55 a 2.4.70 con mod_http2, y el módulo independiente mod_h2 2.0.8 a 2.0.42.
- Corrección: la versión 2.4.71, publicada el 11 de noviembre de 2026, según BleepingComputer. Corrige además CVE-2026-106023 (mod_md, importante) y CVE-2026-109163 (mod_vhost_alias, bajo).
- Aviso oficial: INCIBE-CERT lo publicó el 12 de noviembre con importancia 5 (crítica).
- Descubrimiento: el OSS Scanner de Anthropic e investigadores de Google Cloud Vulnerability Research (Anthony Weems y Simon Scannell), según SecurityWeek.
¿Me afecta si mi web la gestiona un proveedor?
Sí, puede afectarte. Apache es un servidor web muy extendido. Da igual que la web, la tienda online, la intranet o el servidor de una aplicación estén en tu oficina, en un hosting o en un servidor gestionado: si corre sobre Apache en una versión vulnerable, el riesgo es el mismo.
La condición clave es HTTP/2. Red Hat indica que solo están afectados los servidores con HTTP/2 activado; los que solo sirven HTTP/1.1 no lo están. HTTP/2 se activa con la directiva Protocols (valores h2 o h2c), ya sea en todo el servidor o en un host virtual concreto. Por eso hay que revisarla en ambos sitios.
Un detalle que confunde: actualizar WordPress u otro CMS no lo arregla. El fallo está en el servidor web, no en la aplicación.
¿Lo están explotando ya?
Las fuentes no coinciden. INCIBE-CERT lo marca como no explotado. Wiz no detectó exploit público ni explotación activa el 11 de noviembre. Red Hat, en cambio, afirma que una investigación pública ha demostrado un exploit fiable.
Lo que sí existe es una prueba de concepto en GitHub. Reproduce la corrupción de memoria y tumba el proceso, aunque no demuestra ejecución remota de código. Traducido: hoy alguien puede dejar tu web caída con herramientas públicas.
¿Ya hay parche para mi distribución de Linux?
Depende de cuál uses. Red Hat ya ha publicado correcciones para RHEL 9 y 10, donde valora el fallo como Importante. RHEL 8 y anteriores no contienen el código vulnerable.
Según The Hacker News, Debian bookworm, trixie y forky figuraban como vulnerables sin parche listado, y Amazon Linux estaba pendiente de corrección. Si usas alguno de ellos, comprueba si el paquete ya está disponible antes de dar el tema por cerrado.
Qué hacer hoy
- Haz la lista de todo lo que sirve web en tu empresa: web corporativa, tienda, intranet, servidores de aplicaciones, hostings y servidores gestionados. Incluye los que mantienes para clientes.
- Pide a tu informático o a tu proveedor de hosting que confirme la versión de Apache. Entre 2.4.55 y 2.4.70 es vulnerable.
- Que revise la directiva Protocols en la configuración general y en cada host virtual. Si aparece h2 o h2c, HTTP/2 está activo.
- Actualiza a Apache 2.4.71 o instala el paquete corregido de tu distribución. En Debian o Amazon Linux, verifica primero que ya exista.
- Si no puedes actualizar hoy, deja Protocols en http/1.1 como mitigación temporal y anota que hay que revertirlo tras parchear.
- Empieza por los servidores expuestos a internet. Son los que la prueba de concepto pública puede tumbar.
Qué significa para una pyme
No esperes a que se aclare si hay explotación activa. Un CVSS de 9.8, sin autenticación y con una prueba de concepto pública que ya provoca caídas basta para tratarlo como urgente. En el peor caso es ejecución de código en tu servidor; en el mejor, tu tienda online fuera de servicio.
El problema real en una pyme no es el parche, que es sencillo. Es saber dónde corre Apache y quién es responsable de actualizarlo. Muchas empresas no conocen la versión de su servidor web porque vive en un hosting contratado hace años. Si tu proveedor no te responde hoy con versión y estado de HTTP/2, ya tienes un dato sobre ese proveedor.
Otro apunte: este fallo lo encontraron herramientas e investigadores de Anthropic y Google. Si los escáneres automáticos aceleran el hallazgo de fallos, conviene tener un proceso de actualización que no dependa de que alguien lea la noticia. Si no tienes claro ese inventario o ese proceso, en ciberseguridad podemos ayudarte a ordenarlo.
Preguntas frecuentes
¿Si mi servidor solo usa HTTP/1.1 estoy a salvo de este fallo?
Según Red Hat, sí: solo están afectados los servidores con HTTP/2 activado. Revisa la directiva Protocols en todo el servidor y en cada host virtual para confirmarlo.
¿Actualizar WordPress resuelve el problema?
No. El fallo está en Apache, el servidor web. Las actualizaciones del CMS no lo tocan.
¿Desactivar HTTP/2 es suficiente?
Es una mitigación temporal. La solución es actualizar a 2.4.71 o al paquete corregido de tu distribución.
Fuentes
- INCIBE-CERT – Múltiples vulnerabilidades en Apache HTTP Server (INCIBE-2026-860)
- SecurityWeek – Apache Patches Critical HTTP Server RCE Found by Anthropic, Google
- The Hacker News – Critical Apache HTTP/2 Flaw Could Let Unauthenticated Attackers Execute Code Remotely
- BleepingComputer – Apache HTTP Server patches critical HTTP/2 remote code execution flaw
