CVE-2024-36401 en GeoServer: la inyección XPath que convierte un servidor de mapas en una shell remota
Por qué un servidor de mapas importa en tu modelo de amenaza
GeoServer no es una aplicación exótica. Es el servidor cartográfico de código abierto que publica datos geoespaciales para portales de catastro, visualizadores meteorológicos, plataformas de urbanismo, atlas sanitarios y cuadros de mando energéticos en administraciones públicas,Utilities y grandes empresas de toda Europa y Latinoamérica. La mayoría de estos despliegues son antiguos, están en una DMZ o directamente expuestos a internet porque la lógica del negocio asume que los mapas son públicos. Esa suposición es exactamente lo que explota CVE-2024-36401.
El 14 de agosto de 2026, Hispasec Unaaldia publicó que la vulnerabilidad crítica en GeoServer ya se explota activamente y permite tomar el control del servidor sin necesidad de credenciales. La cadena combina dos ingredientes: cualquier instancia que publique los endpoints OGC de WFS, WMS o WPS por HTTP y una versión de GeoServer anterior a los parches publicados en junio de 2024. El atacante no necesita autenticarse, no necesita que el usuario haga clic en nada y no necesita una posición en la red interna. Solo necesita que la URL del GeoServer sea accesible desde internet, lo cual es el caso por defecto para decenas de miles de instancias en producción.
El problema no es nuevo. CVE-2024-36401 se divulgó en julio de 2024 y los parches se publicaron en junio de 2024 (versiones 2.25.2 y 2.24.4) y marzo de 2025 (versión 2.22.6). Lo nuevo, y lo que obliga a este artículo, es que dos años después del parche seguimos viendo explotación activa, intrusiones confirmadas y web shells desplegados sobre instancias que nadie actualizó.
Anatomía técnica: cómo una propiedad maliciosa se convierte en ejecución remota
La raíz de la vulnerabilidad está en cómo la librería GeoTools —utilizada por GeoServer— maneja los nombres de propiedades de los features. GeoTools delega la evaluación de esos nombres a la librería commons-jxpath, que permite ejecutar expresiones XPath con capacidad de invocar métodos Java arbitrarios. XPath, en este contexto, no es solo un lenguaje de consulta: es una puerta abierta al runtime de Java.
El detalle clave, descrito por el NVD y el advisory oficial de GeoServer, es que la evaluación XPath debería limitarse a los features complejos del Application Schema. Sin embargo, una falla de implementación hace que esa evaluación se aplique también a los features simples, que son los que usa prácticamente toda instancia de GeoServer por defecto. El resultado: cualquier parámetro de propiedad en una petición OGC se evalúa como XPath completo, lo que permite inyectar llamadas a `java.lang.Runtime.getRuntime().exec()` desde un cliente HTTP externo.
Los parámetros vulnerables incluyen operaciones que GeoServer expone por defecto en sus servicios estándar:
- WFS (Web Feature Service): `GetFeature` y `GetPropertyValue` - WMS (Web Map Service): `GetMap`, `GetFeatureInfo` y `GetLegendGraphic` - WPS (Web Processing Service): `Execute`
La severidad es la máxima posible para una vulnerabilidad de red: CVSS v3.1 de 9.8, con vector `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`. Sin autenticación, sin interacción del usuario, complejidad baja y efectos totales sobre confidencialidad, integridad y disponibilidad.
El EPSS (Exploit Prediction Scoring System) asigna a CVE-2024-36401 una probabilidad de explotación del 94,4 %, en el percentil 100. CISA añadió la vulnerabilidad a su catálogo KEV el 18 de julio de 2024 con fecha límite de remediación del 5 de agosto de 2024 para las agencias federales estadounidenses. Casi dos años después, Hispasec confirma que sigue habiendo intentos activos y compromisos confirmados en producción.
La cadena de ataque que documenta Hispasec
El incidente descrito por Hispasec Unaaldia el 14 de agosto de 2026 no es teórico. La cadena observada en instancias reales sigue un patrón reconocible para cualquier analista que haya visto un compromiso de aplicación web expuesto.
La fase inicial es la explotación directa de CVE-2024-36401. El atacante envía una solicitud HTTP construida contra uno de los endpoints OGC vulnerables con un nombre de propiedad malicioso que contiene una expresión XPath. La expresión invoca el runtime de Java para ejecutar un comando en el sistema operativo. En cuestión de segundos, el proceso de GeoServer —que suele correr con privilegios elevados o, peor, como root dentro del contenedor Docker— ejecuta el payload del atacante.
La segunda fase es la persistencia. Una vez que el atacante tiene ejecución remota, el siguiente movimiento habitual es desplegar un web shell. Hispasec documenta específicamente el uso de China Chopper, una herramienta china de web shell minimalista que cabe en una sola línea y que sigue siendo sorprendentemente común en intrusiones contra infraestructura europea. El web shell se coloca típicamente en el directorio de trabajo de GeoServer, donde pasa desapercibido para las soluciones antivirus porque el directorio está lleno de archivos `.jar`, `.xml` y `.properties` legítimos.
La tercera fase es el reconocimiento interno. Con el web shell en su lugar, el atacante tiene una shell persistente que sobrevive a reinicios del servicio. Desde ahí enumera la red, identifica sistemas adyacentes, busca rutas hacia bases de datos y servicios internos, y prepara movimiento lateral. El web shell es discreto porque las peticiones pasan por el mismo puerto que GeoServer y mezclan su tráfico con las consultas OGC legítimas.
La cuarta fase es el movimiento lateral. Hispasec documenta el uso del web shell para acceder a recursos compartidos, escalar privilegios y comprometer otros sistemas internos. En algunos casos, los atacantes han llegado hasta Active Directory y han desplegado ransomware o herramientas de exfiltración masiva.
Lo más preocupante del patrón es que es genérico. No estamos ante un actor de amenaza sofisticado con zero-days no publicados. Estamos ante explotación masiva de una vulnerabilidad de dos años de antigüedad que sigue siendo efectiva porque hay decenas de miles de instancias sin parchear.
Por qué CVE-2024-36401 sigue activo dos años después del parche
Tres factores se combinan para mantener esta vulnerabilidad en la lista de las más explotadas del mundo.
El primer factor es la superficie de exposición. GeoServer es software de código abierto, gratis y bien documentado. Cualquier administrador con datos geoespaciales lo instala y lo publica. Muchas instalaciones son de aficionados, ONG, ayuntamientos pequeños o proyectos académicos que llevan años sin mantenimiento profesional. Para esas instancias, la actualización es un proyecto de varios días que requiere pruebas, regresión y validación con los datos propios.
El segundo factor es la falsa percepción de seguridad. Un servidor de mapas no transmite la urgencia de un ERP o una base de datos de clientes. Los responsables de seguridad de muchas organizaciones lo ven como infraestructura secundaria, sin datos sensibles. Esa percepción es errónea: un atacante con shell en el servidor GeoServer ve toda la base de datos geoespacial, los metadatos de los servicios internos y, muy a menudo, las credenciales de conexión a bases de datos y servicios externos.
El tercer factor es la disponibilidad pública de PoCs. En GitHub hay múltiples repositorios públicos que automatizan la explotación de CVE-2024-36401, incluido el de Chocapikk. Un atacante con habilidades básicas puede clonar el repositorio, apuntarlo a un servidor GeoServer y obtener shell en minutos. Esta disponibilidad convierte la vulnerabilidad en commodity para los escaneos masivos que realizan los grupos de ransomware y los operadores de botnets.
Playbook DevSecOps para esta semana
### Fase 1 — Inventario y detección de exposición (horas 0 a 12)
El primer movimiento es saber qué tienes. Muchas organizaciones descubren en esta fase que tienen instancias GeoServer de las que nadie se acuerda.
- Identificar todas las instancias de GeoServer en el inventario. Incluir instancias on premise, en la nube pública, en contenedores Docker y en Kubernetes. Las imágenes Docker antiguas son una fuente común de instancias olvidadas. - Para cada instancia, comprobar la versión exacta de GeoServer y compararla contra las versiones fijas: 2.25.2, 2.24.4 y 2.22.6 (esta última publicada en marzo de 2025). Cualquier versión anterior está afectada. - Determinar si la instancia expone endpoints OGC a internet. La forma más rápida es hacer una petición HTTP a `https://tu-instancia/geoserver/ows?service=WFS&version=2.0.0&request=GetCapabilities` desde una red externa. Si devuelve capabilities XML, está expuesta. - Revisar los logs de acceso de GeoServer en busca de patrones que indiquen intentos de explotación: nombres de propiedades con caracteres especiales, expresiones que contengan `java.`, `Runtime`, `exec`, `ProcessBuilder`, o patrones de XPath complejos. - Buscar indicadores de compromiso conocidos en el servidor: procesos hijos inesperados del proceso Java de GeoServer, conexiones salientes desde el servidor hacia destinos desconocidos, archivos `.jsp`, `.php` o scripts desconocidos en el árbol de directorios de GeoServer, cuentas de usuario nuevas o modificaciones recientes en los archivos de configuración.
### Fase 2 — Contención inmediata (horas 12 a 36)
Si detectas instancias vulnerables expuestas a internet, la prioridad es cortar el acceso externo mientras se planifica la actualización.
- Bloquear el acceso externo al servidor mediante reglas de firewall, lista de control de acceso del balanceador o, si la instancia está en una DMZ, restringir el acceso a las IPs internas conocidas. - Si no es factible cortar el acceso de inmediato, implementar autenticación básica HTTP como mitigación temporal. Esto rompe la cadena de explotación automática de los escáneres masivos. - Si la instancia ya muestra signos de compromiso, aislarla de la red para análisis forense. No apagar el servidor — el análisis forense en frío pierde artefactos valiosos. - Auditar las cuentas administrativas del servidor, las claves SSH y las credenciales almacenadas en archivos de configuración. Asumir compromiso de credenciales si hay cualquier indicio de intrusión.
### Fase 3 — Remediación (días 2 a 7)
- Actualizar GeoServer a la versión fija más reciente de la rama que uses. Si estás en 2.22.x, actualizar a 2.22.6. Si estás en 2.24.x, actualizar a 2.24.4. Si estás en 2.25.x, actualizar a 2.25.2 o posterior. - Antes de actualizar en producción, validar la actualización en un entorno de pruebas con los mismos datos y configuraciones. GeoServer tiene extensiones y plugins que pueden requerir pasos adicionales. - Si la instancia corre como contenedor Docker, reconstruir la imagen base con la versión parcheada y redesplegar. Verificar que la nueva imagen no incluye versiones heredadas de las dependencias. - Si no puedes actualizar de inmediato por incompatibilidad con extensiones o datos propietarios, aplicar el workaround documentado por GeoServer: instalar las versiones parcheadas de GeoTools sin actualizar GeoServer. Esto mitiga la vulnerabilidad sin romper las extensiones. - Reiniciar el servicio tras la actualización para asegurar que la nueva versión está activa. Verificar la versión reportada en la interfaz de administración o en la respuesta de `GetCapabilities`.
### Fase 4 — Verificación y monitoreo (días 7 a 14)
- Re-escanear la instancia con un escáner de vulnerabilidades actualizado para confirmar que el fix está reportado como instalado. - Implementar detección de intentos de explotación en los logs. Configurar alertas para solicitudes OGC con nombres de propiedades que contengan caracteres especiales o expresiones XPath complejas. - Si la instancia almacena credenciales o conecta a bases de datos externas, rotar todas las credenciales de acceso. Asumir que cualquier credencial accesible desde el servidor durante el período de exposición está comprometida. - Documentar el incidente en el repositorio de lecciones aprendidas, incluyendo el tiempo desde la divulgación hasta la remediación efectiva.
Errores sistemáticos que cometen los equipos
Error uno — tratar GeoServer como infraestructura secundaria. Un servidor cartográfico comprometido es una puerta de entrada a la red interna y a los datos geoespaciales que protege. Tratarlo como infraestructura de bajo riesgo es un error de modelo de amenaza.
Error dos — confiar en la DMZ como barrera suficiente. Una instancia GeoServer expuesta a internet en una DMZ es accesible para cualquier atacante con un escáner. La DMZ no mitiga CVE-2024-36401; solo cambia quién puede intentar explotar la vulnerabilidad.
Error tres — olvidar instancias en producción. Muchas organizaciones tienen instancias GeoServer desplegadas por equipos de proyecto que ya no existen, mantenidas por personas que han rotado a otros puestos, o ejecutándose como sidecars de aplicaciones que ya fueron deprecadas. Esas instancias son las primeras que aparecen en los escaneos masivos.
Error cuatro — ignorar el historial de commits de GeoTools. CVE-2024-36401 es la punta visible. La causa raíz está en GeoTools, la librería que usa GeoServer para procesar datos geoespaciales. Vulnerabilidades similares pueden existir en otros componentes de la pila que no han sido parcheados.
El párrafo para liderazgo
Si necesitas el párrafo para un comité de seguridad: CVE-2024-36401 es una vulnerabilidad de ejecución remota de código en GeoServer, con CVSS 9.8, explotable de forma masiva desde julio de 2024 y activamente explotada en 2026 según Hispasec. Permite a un atacante remoto no autenticado tomar el control del servidor mediante una solicitud HTTP maliciosa contra los endpoints OGC estándar. Afecta a cualquier versión de GeoServer anterior a 2.22.6, 2.24.4 y 2.25.2. La mitigación pasa por actualizar las instancias afectadas, validar la ausencia de compromiso, y bloquear el acceso externo a instancias que no puedan actualizarse de inmediato. La superficie de exposición típica incluye portales cartográficos de administraciones públicas,Utilities y plataformas de urbanismo que llevan años sin mantenimiento profesional.
Cambios estructurales después de este incidente
Cambio uno — GeoServer como activo crítico en el modelo de amenaza. Si tu inventario trata GeoServer como plataforma de bajo riesgo, este incidente lo invalida. Cualquier plataforma con un CVE activo de RCE sin autenticación y EPSS superior al 90 % merece tratamiento de activo crítico.
Cambio dos — revisión trimestral de versiones de plataformas open source. Un procedimiento programado que verifique las versiones de todas las plataformas open source desplegadas contra bases de datos de vulnerabilidades conocidas. La métrica correcta es "porcentaje de instancias en versiones soportadas", no "instalo cuando tengo tiempo".
Cambio tres — alerta temprana sobre PoCs públicos. Una vez que un PoC funcional para una vulnerabilidad de tu stack aparece en GitHub, el reloj empieza a correr. Integrar feeds de PoCs públicos en el flujo de priorización de parches.
Cambio cuatro — segmentación de servidores de mapas. Los servidores GeoServer que sirven datos públicos no necesitan acceso a bases de datos internas ni a redes corporativas. La segmentación de red reduce el blast radius de un compromiso.
Fuentes verificadas
- Hispasec Unaaldia, "Una vulnerabilidad crítica en GeoServer se explota activamente y permite tomar el control del servidor", 14 de agosto de 2026. https://unaaldia.hispasec.com/una-vulnerabilidad-critica-en-geoserver-se-explota-activamente-y-permite-tomar-el-control-del-servidor-2/ - NVD, "CVE-2024-36401 Detail". https://nvd.nist.gov/vuln/detail/cve-2024-36401 - GeoServer Project, "CVE-2024-36401 Remote Code Execution (RCE) vulnerability in evaluating property name expressions", 12 de septiembre de 2024. https://geoserver.org/vulnerability/2024/09/12/cve-2024-36401.html - SecPod, "GeoServer Critical RCE Flaw Actively Exploited, Warns CISA", julio de 2024. https://www.secpod.com/learn/security-research/geoserver-critical-rce-flaw-actively-exploited-warns-cisa - turingpoint, "CVE-2024-36401 - OSGeo GeoServer GeoTools Eval Injection Vulnerability". https://turingpoint.de/en/cve/CVE-2024-36401 - Chocapikk, "CVE-2024-36401: GeoServer Remote Code Execution", GitHub. https://github.com/Chocapikk/CVE-2024-36401
Recomendaciones de cierre
Aplica los parches de junio de 2024 o marzo de 2025 sobre cada instancia de GeoServer en producción. Si una instancia no puede actualizarse de inmediato, impleméntala el workaround documentado por GeoServer basado en GeoTools parcheada o bloquéala desde internet. Audita logs en busca de patrones de explotación compatibles con CVE-2024-36401. Si detectas indicadores de compromiso, asume credential stuffing sobre todos los secretos accesibles desde el servidor. Trátalo como activo crítico en tu modelo de amenaza, no como infraestructura secundaria. La diferencia entre esos dos marcos es lo que separa a los equipos que contienen el incidente de los que descubren el web shell cuando ya es demasiado tarde.