GeoNetwork: dos fallos permiten RCE sin autenticación en geoportales públicos

Una cadena de ataque contra el backend geoespacial

GeoNetwork ha corregido dos vulnerabilidades que, combinadas, permiten a un atacante anónimo ejecutar código en el servidor que aloja un geoportal. Los parches están disponibles en las versiones 4.4.12 y 4.2.17, publicadas el 8 de julio de 2026. Los detalles técnicos se hicieron públicos el 31 de agosto de 2026.

La cadena combina un endpoint de carga sin controles de autorización adecuados con una configuración insegura del procesador XSLT Saxon. El primer fallo permite depositar un formatter malicioso en el servidor; el segundo convierte ese archivo en un medio para ejecutar comandos del sistema operativo.

Las vulnerabilidades están identificadas como:

• CVE-2026-63219, con una puntuación CVSS comunicada de 8.6;
• CVE-2026-58400, con una puntuación CVSS comunicada de 9.1.

Las fichas asociadas de GitHub Security Advisory no asignan puntuaciones CVSS. Estos valores proceden de la reconstrucción periodística del incidente.

GeoNetwork es un catálogo open source de metadatos geoespaciales, creado en la Organización de las Naciones Unidas para la Alimentación y la Agricultura y mantenido bajo el paraguas de la Open Source Geospatial Foundation (OSGeo). Se utiliza como componente backend de infraestructuras de datos espaciales y geoportales públicos, incluido el sistema europeo INSPIRE.

La carga anónima abre el camino al archivo XSLT malicioso

El primer fallo, CVE-2026-63219, afecta al endpoint utilizado para cargar los formatters de GeoNetwork. La ausencia de un control de autorización permite a un usuario no autenticado enviar archivos con extensión .xsl o .zip, que se guardan en el directorio correspondiente.

El problema está documentado en el advisory GHSA-mh22-prqr-vf42 y afecta a los siguientes paquetes Maven:

• org.geonetwork-opensource:gn-services
• org.geonetwork-opensource:gn-web-app

Las versiones vulnerables indicadas son:

• GeoNetwork 4.4.x hasta la 4.4.11 incluida;
• GeoNetwork 4.2.x hasta la 4.2.16 incluida.

Incluso sin combinarlo con otros fallos, la vulnerabilidad permite escribir sin autorización en el almacenamiento de la aplicación. En este caso, sin embargo, el contenido cargado puede ser interpretado posteriormente por un componente capaz de interactuar con Java.

Según el proveedor de seguridad Ethiack, el origen de la cadena se remontaría a la reestructuración del endpoint de los formatters introducida en la versión 4.0.6, durante la cual se habría eliminado la comprobación de autorizaciones. El descubrimiento se atribuye al investigador Rafael Castilho.

Para las tareas de inventario y remediación deben utilizarse, en cualquier caso, los intervalos confirmados en los advisories: las ramas 4.4.x y 4.2.x hasta las respectivas versiones vulnerables indicadas.

Saxon convierte el formatter en ejecución de comandos

El segundo problema, CVE-2026-58400, reside en la forma en que GeoNetwork configura Saxon, el procesador utilizado para las transformaciones XSLT. Una hoja de estilo procesada en el servidor puede acceder a funciones Java utilizables para crear procesos, entre ellas:

• java.lang.Runtime.exec();
• java.lang.ProcessBuilder.

Por tanto, un atacante puede insertar en el formatter instrucciones que ejecuten comandos en el sistema operativo. El código se ejecuta con los privilegios de la cuenta que gestiona el proceso de GeoNetwork, no necesariamente con privilegios administrativos en el sistema.

El advisory GHSA-x898-729x-cc3r señala como afectado el paquete Maven:

org.geonetwork-opensource:gs-web-app

También en este caso son vulnerables las versiones de GeoNetwork hasta la 4.4.11 y hasta la 4.2.16, mientras que las correcciones están incluidas en las versiones 4.4.12 y 4.2.17.

La configuración descrita mantiene habilitado el secure processing y desactiva las extensiones Java. A pesar de estos ajustes, el formatter podría acceder igualmente a las primitivas necesarias para ejecutar comandos.

Considerada de forma aislada, CVE-2026-58400 requiere que el atacante pueda cargar previamente un formatter. CVE-2026-63219 elimina precisamente este requisito, haciendo que toda la secuencia sea accesible sin credenciales.

El ataque se desarrolla en seis pasos:

1. se envía un formatter XSLT malicioso al endpoint desprotegido;
2. GeoNetwork guarda el archivo en el directorio de los formatters;
3. el atacante solicita mediante GET un registro público;
4. la visualización del registro activa Saxon;
5. la hoja XSLT invoca Runtime.exec() o ProcessBuilder;
6. el comando es ejecutado por el backend con los privilegios del servicio de GeoNetwork.

Una intrusión podría exponer datos, configuraciones y credenciales accesibles para la aplicación. El servidor también podría convertirse en un punto de apoyo para desplazarse por la infraestructura que aloja la Spatial Data Infrastructure.

Cientos de instalaciones expuestas, pero ninguna víctima confirmada

Ethiack declaró haber identificado 121 despliegues de GeoNetwork expuestos a Internet y vulnerables, distribuidos en 39 países. Según la misma medición, el 89 % de las instancias reconocidas mediante fingerprinting correspondería a organismos gubernamentales, organizaciones militares o agencias nacionales.

Estas cifras no equivalen a 121 sistemas comprometidos. Describen sistemas que serían accesibles y utilizarían versiones vulnerables, según la estimación de un único proveedor.

No se han hecho públicas pruebas de explotación de la cadena en ataques reales. En el momento de la divulgación, CVE-2026-63219 y CVE-2026-58400 tampoco figuraban en el catálogo Known Exploited Vulnerabilities (KEV) de CISA.

La ausencia en el KEV significa que no existía una confirmación de CISA sobre explotación activa. Sin embargo, no reduce la gravedad técnica: el endpoint es accesible de forma remota, el primer paso no requiere autenticación y la activación puede producirse mediante la solicitud de un registro público.

Actualización inmediata y bloqueo temporal del endpoint

La corrección definitiva consiste en actualizar GeoNetwork a una de las versiones protegidas:

• 4.4.12 para las instalaciones de la rama 4.4.x;
• 4.2.17 para las de la rama 4.2.x.

Quienes no puedan aplicar el parche de inmediato deberían impedir, mediante un reverse proxy, las operaciones de escritura dirigidas a:

/geonetwork/srv/api/formatters

En Apache httpd deben denegarse, para esta ruta, las solicitudes:

• POST;
• PUT;
• PATCH.

En Nginx, la mitigación propuesta consiste en permitir exclusivamente:

• GET;
• HEAD;
• OPTIONS.

La restricción también afecta a las actividades legítimas: los administradores no podrán cargar formatters desde la consola mientras el bloqueo permanezca activo.

No hay indicadores de compromiso específicos disponibles. Las comprobaciones deberían centrarse en los registros del reverse proxy y de la aplicación, buscando cargas de archivos .xsl o .zip dirigidas al endpoint de los formatters.

También requieren atención las solicitudes GET a registros públicos inmediatamente posteriores a una carga. En el sistema operativo deben revisarse además los procesos, shells o comandos inusuales iniciados por la cuenta de servicio de GeoNetwork.

Los antecedentes de GeoServer que ya entraron en el catálogo KEV

El caso se suma a una serie de vulnerabilidades que también han afectado a GeoServer, otro software fundamental para las infraestructuras geoespaciales.

CVE-2024-36401, con un CVSS de 9.8, permitía la RCE sin autenticación mediante parámetros OGC manipulados y la evaluación insegura de expresiones XPath. Afectaba a GeoServer anterior a la 2.22.6 y a GeoTools anterior a la 29.6; las correcciones indicadas para GeoServer también incluyen las versiones 2.23.6, 2.24.4 y 2.25.2.

La vulnerabilidad figura en el catálogo CISA KEV desde el 15 de julio de 2024, con una fecha límite de remediación para las agencias federales estadounidenses fijada en el 5 de agosto de 2024. CISA exigió aplicar las mitigaciones del proveedor o dejar de utilizar el producto cuando no estuvieran disponibles. El fallo se vinculó a ataques realizados por botnets, mineros de criptomonedas y la backdoor SideWalk.

También CVE-2025-58360, una vulnerabilidad XXE con un CVSS de 8.2, entró en el KEV. El fallo afectaba a las entradas XML enviadas a la operación GetMap de /geoserver/wms y se corrigió en GeoServer 2.25.6, 2.26.3 y 2.27.0.

CVE-2025-58360 está presente en el catálogo desde el 11 de diciembre de 2025, con una fecha límite federal del 1 de enero de 2026. CISA exigió aplicar las mitigaciones del proveedor, implementar las indicaciones pertinentes del BOD 22-01 para los servicios cloud o interrumpir el uso cuando no hubiera contramedidas disponibles.

En el caso de GeoNetwork, en el momento de la divulgación no existía una evidencia pública equivalente de explotación. Aun así, la combinación de carga anónima y transformaciones XSLT en el servidor obliga a tratar la actualización como prioritaria, especialmente en los geoportales directamente expuestos a Internet.