Apache Software Foundation ha publicado Apache HTTP Server 2.4.67, una actualización de seguridad que corrige varias vulnerabilidades en uno de los servidores web más usados del mundo. La más delicada es CVE-2026-23918, un fallo de doble liberación de memoria en la implementación de HTTP/2 que, en el peor escenario, podría permitir ejecución remota de código o provocar la caída del proceso vulnerable.
La recomendación para administradores es directa: revisar versiones y actualizar cuanto antes. CVE-2026-23918 afecta específicamente a Apache HTTP Server 2.4.66, pero la versión 2.4.67 corrige también otros fallos presentes en versiones anteriores. En entornos con hosting compartido, paneles de control, balanceadores, reverse proxies o aplicaciones críticas expuestas a Internet, dejar la actualización para más adelante no es una buena opción.
Un doble free en HTTP/2 con impacto potencial grave
CVE-2026-23918 se produce en el manejo de HTTP/2 durante una secuencia de “early reset”. A nivel práctico, el problema aparece cuando el servidor libera dos veces la misma zona de memoria en una ruta concreta de gestión de streams. Este tipo de error, conocido como double free, puede corromper estructuras internas del heap y abrir la puerta a comportamientos peligrosos: desde una denegación de servicio hasta, en determinadas condiciones, ejecución remota de código.
Apache clasifica el fallo como “important” y lo describe como “double free and possible RCE”. Otros organismos y proveedores le asignan una puntuación CVSS de 8,8, dentro del rango alto. No conviene traducir esto automáticamente como “explotación garantizada”, porque convertir una corrupción de memoria en ejecución fiable depende de muchos factores: sistema operativo, compilación, mitigaciones, configuración, módulos cargados y entorno de ejecución. Pero sí es una vulnerabilidad que debe tratarse como prioritaria.
El fallo fue comunicado al equipo de seguridad de Apache el 10 de diciembre de 2025 por Bartlomiej Dmitruk, de striga.ai, y Stanislaw Strzalkowski, de isec.pl. La corrección se incorporó al árbol de desarrollo al día siguiente y se publicó de forma general con Apache HTTP Server 2.4.67 el 4 de mayo de 2026.
HTTP/2 está muy extendido en infraestructuras modernas porque mejora el rendimiento frente a HTTP/1.1 en muchos escenarios, permite multiplexación y reduce parte de la latencia percibida. Precisamente por eso una vulnerabilidad en esta capa tiene tanto alcance operativo. Muchos administradores no piensan a diario en mod_http2, pero lo tienen activo en servicios públicos, entornos de hosting, APIs, portales corporativos y aplicaciones detrás de proxies.
mod_rewrite, AJP, OCSP y WebDAV también reciben correcciones
La actualización 2.4.67 no se limita a HTTP/2. Otra vulnerabilidad relevante es CVE-2026-24072, un problema de escalada de privilegios relacionado con el uso de expresiones ap_expr en varios módulos, incluido mod_rewrite. Apache indica que el fallo permite a autores locales de .htaccess leer archivos con los privilegios del usuario httpd.
Este matiz importa mucho en proveedores de hosting, servidores compartidos y entornos donde diferentes usuarios pueden subir o modificar ficheros .htaccess. En un servidor dedicado a una única aplicación, el riesgo puede ser más acotado. En una plataforma multiusuario, en cambio, cualquier fallo que rompa los límites esperados de acceso local puede tener consecuencias serias.
También se corrige CVE-2026-28780, un desbordamiento de búfer basado en heap en mod_proxy_ajp. Según Apache, el problema puede activarse si mod_proxy_ajp conecta con un servidor AJP malicioso, que podría devolver un mensaje especialmente preparado y provocar una escritura controlada más allá del final de un búfer. No todos los servidores Apache usan AJP, pero quienes lo mantengan por integraciones con Tomcat u otros backends deberían revisar la exposición.
CVE-2026-29168 afecta a mod_md mediante respuestas OCSP sin límites suficientes, lo que puede derivar en consumo excesivo de recursos. CVE-2026-29169, por su parte, es una desreferencia de puntero nulo en mod_dav_lock que puede permitir bloquear el servidor con una petición maliciosa. Apache señala que mod_dav_lock no es usado internamente por mod_dav ni por mod_dav_fs, y recomienda eliminarlo si no puede aplicarse la actualización de inmediato.
La propia página de vulnerabilidades de Apache recoge además otros fallos corregidos en 2.4.67, como problemas en mod_auth_digest, mod_authn_socache y varios casos relacionados con mod_proxy_ajp. Esto refuerza la idea de que la actualización no debe abordarse como un parche aislado para HTTP/2, sino como una revisión general de seguridad del servidor.
Qué deben hacer los administradores
La primera medida es identificar versiones reales en producción. No basta con revisar la versión declarada en inventario si los servidores se gestionan con imágenes antiguas, contenedores sin reconstruir o paquetes mantenidos por paneles de hosting. Hay que comprobar qué Apache está ejecutándose realmente y desde qué repositorio se actualiza.
La segunda medida es actualizar a Apache HTTP Server 2.4.67 o al paquete corregido que proporcione cada distribución. En Debian, por ejemplo, el aviso DSA-6248-1 confirma correcciones para bookworm y trixie, con versiones específicas de paquete. En distribuciones empresariales, paneles de control y stacks gestionados, lo prudente es seguir el canal oficial del proveedor y verificar si el paquete incorpora backports aunque el número de versión externo no sea exactamente 2.4.67.
Después de actualizar, conviene reiniciar o recargar el servicio de forma controlada, revisar logs y comprobar que los módulos afectados siguen siendo necesarios. Muchos servidores cargan módulos por herencia histórica: AJP que ya no se usa, WebDAV antiguo, configuraciones .htaccess demasiado permisivas o HTTP/2 habilitado sin una revisión reciente de seguridad. La actualización corrige los fallos conocidos, pero también es buen momento para reducir superficie.
En entornos críticos, la lista de tareas debería incluir pruebas en staging, validación de configuración, comprobación de virtual hosts, revisión de balanceadores y monitorización posterior al despliegue. Si Apache está detrás de un proxy inverso o un CDN, no debe asumirse automáticamente que el riesgo desaparece. Depende de si el tráfico HTTP/2 llega hasta Apache, de cómo se terminan las conexiones y de qué módulos están activos en el backend.
También es recomendable revisar políticas de .htaccess. Cuando se permite a usuarios locales modificar reglas de reescritura u otras directivas, la superficie de ataque aumenta. En servidores modernos y controlados, muchas veces resulta más seguro centralizar configuración en los virtual hosts y limitar AllowOverride a lo estrictamente necesario.
La publicación de Apache 2.4.67 recuerda una lección conocida pero fácil de olvidar: las piezas maduras también fallan. Apache HTTP Server lleva décadas sosteniendo una parte importante de la web, pero su estabilidad no elimina la necesidad de parcheo rápido, configuración mínima y revisión periódica de módulos. En seguridad web, lo peligroso no suele ser solo la vulnerabilidad llamativa, sino la combinación de software desactualizado, módulos innecesarios y ventanas de mantenimiento que se aplazan demasiado.
Preguntas frecuentes
¿Qué versión corrige estas vulnerabilidades de Apache?
Apache HTTP Server 2.4.67 corrige CVE-2026-23918 y varias vulnerabilidades adicionales. Las distribuciones pueden publicar paquetes parcheados con numeraciones propias o backports.
¿CVE-2026-23918 afecta a todas las versiones anteriores?
Según Apache, CVE-2026-23918 afecta a Apache HTTP Server 2.4.66. Otras vulnerabilidades corregidas en 2.4.67 sí afectan a versiones anteriores hasta distintos rangos.
¿Qué riesgo tiene el fallo de HTTP/2?
Es un doble free en la implementación de HTTP/2 que puede provocar corrupción de memoria. Apache lo describe como posible RCE, aunque la explotación práctica dependería de condiciones concretas del entorno.
¿Qué hago si no puedo actualizar inmediatamente?
Reducir superficie ayuda: desactivar módulos no usados, revisar HTTP/2, eliminar mod_dav_lock si no es necesario, limitar .htaccess y aplicar mitigaciones del proveedor. Aun así, la actualización debe ser la prioridad.
