Apache publicó httpd 2.4.69 el 1 de octubre de 2026 con 20 vulnerabilidades corregidas, calificadas como bajas (15) o moderadas (5). No es una emergencia, pero todos los servidores Apache deben actualizarse en la próxima ventana de mantenimiento, mediante los paquetes de su distribución y no persiguiendo el número de versión.

Qué se corrige

La Apache Software Foundation publicó el 1 de octubre de 2026 la versión 2.4.69 de su servidor web. Cierra 20 vulnerabilidades: 15 calificadas como bajas y 5 como moderadas por el equipo de seguridad de Apache. La mayoría están en módulos opcionales, así que su exposición real depende de lo que tenga activado. Las que merecen atención:

  • mod_http2 (CVE-2026-57941, moderada): un uso de memoria liberada en el módulo HTTP/2, activo en muchos sitios modernos.
  • mod_vhost_alias (CVE-2026-63292, moderada): un desbordamiento de pila que podría permitir ejecutar código, pero solo con VirtualDocumentRoot basado en el nombre de host y LimitRequestFieldSize elevado por encima de su valor por defecto.
  • WebDAV (CVE-2026-42528 y CVE-2026-93546, moderadas): caídas y corrupción que requieren un cliente autorizado a bloquear o escribir recursos.
  • CGI (CVE-2026-42356, baja): algunas redirecciones internas pueden hacer que un archivo se ejecute como programa CGI (versiones 2.4.60 a 2.4.68).
  • También se corrigen: contrabando de respuestas mediante mod_proxy_uwsgi, varias debilidades de mod_auth_digest y un fallo de rutas exclusivo de Windows.

Actualizar sin sorpresas

  1. Use los paquetes de su distribución. Debian, Ubuntu, Red Hat y sus derivadas incorporan las correcciones de seguridad sin cambiar el número de versión: un servidor que muestra 2.4.62 puede estar totalmente parcheado. Consulte el aviso de la distribución o el changelog del paquete en lugar de fiarse solo de apachectl -v.
  2. Localice las actualizaciones pendientes con apt list --upgradable o dnf updateinfo list --security y aplíquelas a medida que su distribución las publique.
  3. Priorice los servidores que usan HTTP/2, WebDAV, CGI, VirtualDocumentRoot o un back-end uWSGI.
  4. Pruebe y recargue: apachectl configtest antes de un reinicio suave, para que un error de configuración nunca tumbe el sitio.

Nuestra opinión

Es una versión rutinaria, no una alarma, pero la rutina es precisamente lo que se olvida. Desactive los módulos que no usa (cada uno de estos fallos está en un módulo que muchos sitios cargan sin necesidad) y mantenga un ciclo de parches regular para aplicar este tipo de versiones en días, no en meses.

Fuentes

¿Le preocupa que sus servidores estén expuestos? Nuestro equipo audita, parchea y supervisa infraestructuras Linux y cloud 24/7.

Hablar con un experto