Apache corrige en la versión 2.4.71 un fallo que permite ejecutar código sin autenticación

Si Apache sirve tu sitio web o tu API mediante HTTP/2, el equipo de infraestructura tiene una tarea urgente: comprobar la versión e instalar la corrección. En el módulo que procesa este protocolo se ha encontrado un fallo que permite a un atacante ejecutar código sin autenticación. Por ejemplo, podría estar en riesgo el servidor situado delante de tu aplicación: para este ataque no hace falta la contraseña del panel de administración.

Apache publicó la corrección el 11 de noviembre en la versión 2.4.71. La vulnerabilidad recibió el identificador CVE-2026-119618 y una calificación de gravedad crítica. Según el aviso oficial de Apache, están afectadas las versiones 2.4.55–2.4.70. Es un motivo concreto para revisar el inventario de servidores, averiguar dónde se utiliza HTTP/2 y asignar un responsable de la actualización.

Qué falló dentro del servidor

El fallo se encuentra en mod_http2, en la función assign_headers(). Varios hilos acceden a recursos compartidos sin la sincronización adecuada. Como resultado, el servidor puede corromper su propia memoria, y un atacante puede aprovechar esa corrupción para ejecutar código.

Imagina a dos empleados que editan al mismo tiempo una misma línea de un pedido. Uno cambia su contenido mientras el otro sigue trabajando con el estado anterior. En un servidor web, esta falta de coordinación es peligrosa: afecta a la memoria de un proceso en ejecución. Es una analogía simplificada de la causa del fallo, no la descripción de un método de ataque listo para usar.

Un ejemplo práctico es un servidor Apache situado delante de un servicio de suscripción. Aunque el acceso a la cuenta esté protegido con autenticación multifactor, el procesamiento del protocolo de red ocurre antes de que la aplicación autentique al usuario. Por tanto, reforzar las contraseñas no resuelve este problema concreto. El equipo debe corregir el componente que recibe las peticiones.

Qué hicieron Anthropic y Google

Apache reconoció entre quienes descubrieron la vulnerabilidad a Anthropic OSS Scanner, así como a Anthony Weems y Simon Scannell, de Google Cloud Vulnerability Research. El informe de Anthropic llegó el 26 de octubre y el de Google, el 3 de noviembre. Estos datos confirman la participación del escáner de Anthropic en el descubrimiento de un fallo grave en un software de servidor ampliamente utilizado.

Pero la expresión «la IA encontró una vulnerabilidad» oculta un detalle importante: el registro oficial menciona un escáner concreto y a investigadores concretos. No permite concluir que ambos hallazgos fueran completamente autónomos ni que ya no hagan falta personas para verificar los resultados. Para quienes desarrollan herramientas de seguridad, lo interesante es el resultado: la búsqueda automatizada detectó un fallo en la interacción entre hilos capaz de provocar la ejecución de código.

Las cifras requieren una lectura cuidadosa. Según Wiz, el 64% de los entornos de nube observados contiene recursos con versiones vulnerables, y el 51% incluye instancias accesibles públicamente. La empresa aclara expresamente que estas estimaciones no tienen en cuenta la configuración. Por tanto, el número de instalaciones no indica cuántos servidores pueden ser atacados realmente a través de HTTP/2.

Cuando Wiz publicó su informe el 11 de noviembre, no había ningún exploit público ni informes de explotación. Es una fotografía de una fecha concreta: no garantiza la ausencia de ataques ni describe la situación una semana después.

Qué debe comprobar tu equipo

Empieza por los servidores expuestos a internet: identifica la versión de Apache, la presencia de mod_http2 y el uso real de HTTP/2. Si hay otro proxy delante de la aplicación, averigua qué protocolo llega a Apache. La mera presencia de un servicio intermediario no responde a esa pregunta.

Después, instala la corrección de Apache 2.4.71 o la actualización del paquete correspondiente de tu proveedor del sistema. En los paquetes con correcciones incorporadas a versiones anteriores, sigue el aviso del proveedor: el número de la versión base, por sí solo, puede no indicar si el parche está aplicado. Tras actualizar, comprueba el arranque del servidor, la configuración y los principales flujos de uso.

Si es necesario aplazar la actualización, Wiz propone desactivar temporalmente HTTP/2. Después del cambio, verifica que los clientes pueden acceder al servicio y que el protocolo afectado está realmente desactivado. Es una medida temporal hasta instalar la corrección.

Para responsables de producto y fundadores, la tarea es muy concreta: dar al equipo tiempo para actualizar y obtener confirmación de qué servidores se han revisado. Ese resultado es más útil que una afirmación genérica de que «la seguridad está bajo control».