GeoServer, el motor de mapas de código abierto basado en Java más extendido, se enfrenta a una de sus crisis de seguridad más graves con la vulnerabilidad CVE-2024-36401 (CVSS 9.8). No es un riesgo teórico: los atacantes ya la están explotando en entornos reales para desplegar malware y tomar el control de servidores vulnerables. Como responsables de infraestructura, cloud o seguridad, este es uno de esos escenarios donde no se puede posponer el mantenimiento.
El fallo en la evaluación de expresiones de GeoTools
La raíz del problema no está en el core de GeoServer en sí, sino en cómo la biblioteca subyacente GeoTools gestiona la evaluación de expresiones de tipo XPath. El componente vulnerable procesa parámetros de entrada en peticiones de servicios OGC (como WFS, WMS o WCS) sin una sanitización adecuada antes de pasarlos a la biblioteca Apache Commons JXPath. Un atacante no autenticado puede enviar una petición HTTP POST o GET maliciosa, forzando al motor a ejecutar código Java arbitrario en el servidor con los privilegios del proceso de GeoServer. Esto se traduce en un compromiso total del host.
Sistemas expuestos y alcance del riesgo en producción
La infraestructura SIG (Sistemas de Información Geográfica) suele estar expuesta públicamente para servir mapas a aplicaciones web, portales de datos abiertos de administraciones públicas y servicios corporativos. Si manejas instancias de GeoServer expuestas en AWS, Azure o en tu propio entorno local (bare metal, máquinas virtuales o contenedores Docker) corriendo versiones anteriores a las corregidas, estás en la diana. El exploit público ya circula por repositorios comunes y la automatización del escaneo hace que cualquier máquina visible sea comprometida en cuestión de horas.
Acciones de mitigación y actualización de emergencia
La solución definitiva es actualizar inmediatamente a las versiones seguras publicadas por el proyecto OSGeo: GeoServer 2.23.6, 2.24.4 o 2.25.2 (o superiores).
Si por dependencias internas de tu software o flujos de trabajo no puedes actualizar el servidor hoy mismo, aplica estas dos medidas paliativas de inmediato:
1. Eliminar el JAR problemático: Si no utilizas la funcionalidad de esquemas de aplicación (App-Schema), puedes eliminar de forma segura el archivo 'gt-app-schema-*.jar' del directorio 'WEB-INF/lib' de tu despliegue de GeoServer (habitualmente dentro de la carpeta de Tomcat). Reinicia el servicio tras la eliminación. Esto deshabilita el vector de entrada específico sin romper el resto de servicios estándar de mapas.
2. Filtrado en capa de red (WAF) y Reverse Proxy: Si el servidor está detrás de un Proxy Inverso (Nginx, Traefik, Apache) o un WAF, implementa reglas que bloqueen patrones sospechosos de JXPath en los parámetros de consulta del protocolo WFS. Sin embargo, recuerda que esto es solo una contención temporal y no sustituye el parche oficial.
Es recomendable revisar también los logs del servidor web y de Java en busca de comportamientos extraños, como peticiones inusuales con payloads que referencien 'java.lang.Runtime' o ejecuciones de comandos de consola sospechosos.
Comentarios