Apache 2.4.71 corrige una falla crítica en HTTP/2 que permite tomar el servidor sin contraseña: qué revisar hoy

La Apache Software Foundation publicó el miércoles 11 de noviembre de 2026 la versión 2.4.71 de Apache HTTP Server, y esta vez no hay discusión sobre la gravedad: el propio proyecto califica como crítica la falla principal que corrige. Se trata de CVE-2026-119618, un error en el módulo de HTTP/2 que puede terminar en ejecución remota de código sin autenticación. Red Hat le asigna 9.8 sobre 10 en la escala CVSS.

Es un contraste con la ronda de octubre, cuando Apache 2.4.69 corrigió veinte fallas que el proyecto calificó de bajas o moderadas. Esta es una sola, y es de las que no se dejan para el mes que entra.

Qué se corrigió

La misma versión corrige otras dos: CVE-2026-106023, calificada como importante, que permite tirar procesos del servidor a través de mod_md (el módulo de certificados automáticos), en versiones 2.4.30 a 2.4.70; y CVE-2026-109163, de severidad baja, en mod_vhost_alias, que solo afecta a 2.4.69 y 2.4.70.

¿Ya hay ataques?

Al cierre de esta nota, no hay reportes de explotación. La firma Wiz dijo el 11 de noviembre que no conocía exploits públicos ni ataques, pero advirtió que la situación podía cambiar pronto. SecurityWeek reporta que ya circula en GitHub una prueba de concepto que corrompe la memoria y tira el proceso, sin demostrar todavía ejecución de código; Red Hat, por su parte, habla de investigación pública que demuestra un exploit confiable, sin decir cuál. La firma watchTowr confirmó la falla y lo resumió en una línea: parchar ya o quitar HTTP/2 mientras tanto.

Wiz también dio una cifra que conviene leer con cuidado: 64 % de los entornos de nube que analiza tienen alguna versión afectada y cerca de la mitad la tienen expuesta a internet. Eso cuenta versiones, no configuraciones: no todos tienen HTTP/2 encendido.

El parche todavía no llega a todas las distribuciones

Como siempre con Apache en Linux, casi nadie instala «2.4.71» directo: se recibe el paquete de la distribución. Y hoy, 12 de noviembre, el panorama es desigual:

• Debian 13 (trixie): ya tiene paquete corregido, 2.4.71-1~deb13u1, con el aviso DSA-6620-1.
• Debian 12 (bookworm): el rastreador de seguridad de Debian lista la 2.4.71-1~deb12u1 en el repositorio de seguridad, pero al momento de consultarlo todavía la marcaba como vulnerable. Puede ser un desfase del rastreador; verifica con apt antes de darlo por resuelto.
• Ubuntu: todas las versiones, de la 14.04 a la 26.10, aparecen como «en evaluación». Ubuntu aclara que ha llevado versiones nuevas del módulo a sus versiones estables, así que no asumas que una LTS vieja se salva.
• Red Hat Enterprise Linux: RHEL 8 y anteriores no están afectados, porque su mod_http2 es anterior al código con la falla. En RHEL 9 y 10 Red Hat la baja a «importante»: ahí cada flujo HTTP/2 usa su propia reserva de memoria y eso complica el ataque. La página que consultamos no mostraba todavía erratas con fecha. AlmaLinux y Rocky suelen seguir a Red Hat; no lo verificamos.
• Apache sobre Windows y paquetes tipo XAMPP: no se actualizan con Windows Update. Hay que esperar al empaquetador o instalar la 2.4.71. No encontramos aviso de cPanel ni de otros paneles al cierre.

Qué hacer hoy

1. Haz la lista de servidores con Apache: sitio web, tienda en línea, intranet, sistemas internos en PHP. apachectl -v (o httpd -v) da la versión. Si está entre 2.4.55 y 2.4.70, sigue al paso 2.
2. Revisa si HTTP/2 está activo. Busca la directiva Protocols en la configuración general y en cada sitio virtual, y confirma si el módulo http2 está cargado con apachectl -M.
3. Si hay paquete corregido, actualiza hoy y reinicia el servicio. En Debian 13 ya está.
4. Si no hay paquete, apaga HTTP/2: deja Protocols http/1.1, recarga Apache y comprueba que el sitio responde. Es un cambio de una línea, reversible, y el costo es que las páginas carguen un poco más lento por unos días. Con el Buen Fin arrancando mañana, es mejor una tienda algo más lenta que una tienda comprometida.
5. Si tu sitio está en un hosting compartido o administrado, escribe al proveedor: ¿ya aplicaron la corrección de CVE-2026-119618 o desactivaron HTTP/2? Wordfence lo advirtió con razón: actualizar WordPress no arregla esto, porque la falla está debajo.
6. Si hay un proxy o CDN delante, no lo tomes como exención: ninguna de las fuentes que revisamos dice que eso evite la falla. Revisa si el Apache de origen habla HTTP/2 y si es alcanzable directo desde internet.
7. Guarda evidencia de reinicios raros. La prueba de concepto pública tira procesos; caídas repetidas de Apache en el log de errores a partir del 11 de noviembre merecen una segunda mirada.

Si el servidor nunca ha pasado por una revisión de configuración, los 15 pasos de endurecimiento para Linux son el siguiente pendiente, y si publicas el sitio detrás de otro servidor, la guía de Nginx como proxy inverso explica cómo queda esa capa.

Lo que deja ver esta falla

Dos cosas. La primera: el reporte inicial lo hizo una herramienta automática de análisis con IA, y una semana después llegó un equipo humano de Google al mismo punto por su cuenta. Ayer mismo SecurityWeek contaba que Fortinet corrigió casi cien fallas tras meter modelos de IA a sus pruebas. Lo que encuentran los defensores con esas herramientas también lo pueden encontrar otros, así que el tiempo entre parche y ataque se sigue acortando; en esta misma semana lo vimos con los servidores N-central.

La segunda es la de siempre: el servidor web que nadie recuerda. Las fallas de este mes y las de PHP de octubre pegan en el mismo equipo, el del sistema interno que alguien montó hace años. En Syswork nos encargamos de ese inventario y de mantenerlo al día dentro de servidores y ciberseguridad.