Parche crítico de Apache HTTP Server 2.4.67 ante vulnerabilidad grave de HTTP/2 que podría provocar denegación de servicio y ejecución remota de código

La Fundación Apache ha publicado parches críticos para el servidor HTTP tras el hallazgo de una vulnerabilidad grave en el manejo de HTTP/2 que puede derivar en denegación de servicio y, en determinadas condiciones, en ejecución remota de código. La versión corregida es Apache HTTP Server 2.4.67 y la recomendación inmediata para administradores es actualizar cuanto antes las instancias afectadas que todavía ejecuten 2.4.66 o anteriores.

El problema se sitúa en la lógica de limpieza de flujos de mod_http2 y es un caso clásico de doble liberación de memoria que puede ser disparado por una secuencia de tramas HTTP/2 enviadas por un cliente. En términos prácticos, esto significa que un atacante remoto puede causar que un trabajador se bloquee con un par de paquetes bien formados; la denegación de servicio es trivial de reproducir en despliegues por defecto. La ruta hacia ejecución remota de código (RCE) requiere condiciones adicionales —un asignador de memoria mmap en APR y una cadena de pasos para reutilizar la dirección liberada— pero investigadores han mostrado que es viable en laboratorio bajo las configuraciones comunes en Debian y en la imagen Docker oficial de httpd.

Que la explotación de RCE dependa del asignador mmap y de elementos como el “scoreboard” del servidor convierte a algunas plataformas en objetivos más atractivos: en Debian y en la imagen oficial de Docker el comportamiento por defecto facilita el encadenamiento del exploit. Las configuraciones multi-hilo con mod_http2 habilitado son las más expuestas; el MPM prefork no sufre este fallo, por lo que cambiar temporalmente a prefork puede ser una mitigación parcial en entornos donde no sea posible parchear inmediatamente.

Además del parche, las medidas de mitigación inmediatas que conviene considerar son: actualizar a 2.4.67 en todos los servidores expuestos, deshabilitar mod_http2 si no es estrictamente necesario, y revisar si el APR está usando el asignador mmap (una recompilación de APR sin mmap reduce la ventana de explotación). Para entornos en contenedores, asegúrese de reconstruir y desplegar imágenes basadas en la versión corregida del servidor y valide que las imágenes en producción no sigan usando la versión vulnerable.

Operadores y equipos de seguridad deben monitorizar indicadores claros de abuso: patrones de conexión que causan reinicios repetidos de workers, core dumps, o entradas inusuales en registros de error de httpd. Implementar límites de tasa a nivel de balanceador o cortafuegos, o forzar la terminación de HTTP/2 en un proxy/terminador TLS que esté parcheado, puede contener ataques dirigidos mientras se aplica la actualización en el parque completo.

La vulnerabilidad fue reportada por investigadores independientes y su calificación CVSS (8.8 según el informe) subraya su impacto. Aunque el camino a RCE requiere condiciones técnicas adicionales y un cierto grado de “spray” y fuga de información, los ataques de denegación de servicio son sencillos y suficientes para justificar la prioridad en el parcheo. Para más detalles técnicos y la lista oficial de correcciones consulte la página de seguridad de Apache HTTP Server y la documentación de mod_http2. https://httpd.apache.org/security/vulnerabilities_24.html y https://httpd.apache.org/docs/2.4/mod/mod_http2.html.

En resumen: aplique la versión 2.4.67 cuanto antes, priorice servidores públicos y contenedores basados en Debian o la imagen oficial de httpd, considere mitigaciones temporales como deshabilitar mod_http2 o cambiar a prefork si no puede parchear de inmediato, y aumente la vigilancia de eventos de estabilidad y tráfico anómalo en sus frontales HTTP/2.