Se descubrieron dos vulnerabilidades en GeoNetwork que, al combinarse, permiten la ejecución remota de código sin autenticación. El fallo permite subir archivos maliciosos y ejecutarlos mediante un procesador de transformaciones inseguro, afectando principalmente a portales gubernamentales. Se recomienda actualizar a las versiones 4.4.12 o 4.2.17 para solucionar este problema.

Dos vulnerabilidades en GeoNetwork pueden encadenarse para lograr la ejecución remota de código (RCE) no autenticada en el catálogo de metadatos geoespaciales de código abierto, que se encuentra detrás de muchos geoportales gubernamentales y de agencias.

El proyecto lanzó correcciones en las versiones 4.4.12 y 4.2.17 el 8 de julio de 2026, y publicó los detalles de la vulnerabilidad el 31 de agosto.

GeoNetwork se originó en la Organización para la Alimentación y la Agricultura de las Naciones Unidas y es mantenido por la Open Source Geospatial Foundation (OSGeo). Es un componente central de muchos despliegues de Infraestructura de Datos Espaciales en Europa y otras regiones, incluyendo el backend del geoportal europeo INSPIRE.

La cadena combina una falta de comprobación de autorización con un motor de transformación inseguro. El primer fallo, CVE-2026-63219 (puntuación CVSS: 8.6), es una falta de verificación de autorización en el punto final de carga del formateador.

El fallo de carga de archivos no autenticada permite que un usuario anónimo escriba archivos formateadores .xsl o .zip arbitrarios en el directorio de formateadores de GeoNetwork, lo que, por sí solo, constituye un acceso de escritura no autorizado al almacenamiento del servidor.

"Un atacante no autenticado puede cargar archivos formateadores .xsl o .zip arbitrarios en el servidor", afirmó el proyecto en el aviso [GHSA-mh22-prqr-vf42].

El segundo fallo, CVE-2026-58400 (puntuación CVSS: 9.1), es una configuración insegura del procesador Saxon Extensible Stylesheet Language Transformations (XSLT) utilizado para renderizar los formateadores.

El motor se ejecuta con el procesamiento seguro habilitado y las funciones de extensión de Java desactivadas, por lo que cualquier hoja de estilo que cargue puede llamar a java.lang.Runtime.exec() o java.lang.ProcessBuilder y ejecutar comandos del sistema operativo como el usuario del proceso GeoNetwork.

Por sí solo, ese segundo fallo requiere privilegios para cargar un formateador, razón por la cual se califica como que necesita privilegios altos. Al encadenarlo con el fallo de carga, se elimina esa condición previa, ya que la carga es accesible sin autenticación.



Primero, un atacante carga un formateador malicioso a través del punto final no protegido. Posteriormente, una solicitud GET a un registro público activa el motor Saxon para ejecutar la hoja de estilo, lo que permite la ejecución de código. El proveedor de seguridad Ethiack, cuyo investigador Rafael Castilho informó de los fallos [Ethiack], señaló que la cadena es accesible a partir de la versión 4.0.6, cuando el punto final del formateador fue refactorizado y se eliminó la línea de autorización.

Ethiack afirmó que detectó 121 despliegues de GeoNetwork expuestos a Internet que ejecutaban versiones afectadas en 39 países, y que el 89 por ciento de ellos estaban relacionados con gobiernos, militares o agencias nacionales.

Estas cifras describen instancias expuestas que ejecutan versiones vulnerables, no víctimas confirmadas ni compromisos, y la detección proviene únicamente del proveedor.

Todas las versiones 4.4.x hasta la 4.4.11 inclusive y todas las versiones 4.2.x hasta la 4.2.16 inclusive están afectadas; los fallos se han corregido en las versiones 4.4.12 y 4.2.17.

"Se recomienda encarecidamente a todos los usuarios que actualicen a 4.4.12 o 4.2.17 lo antes posible", indicó el proyecto en su anuncio de lanzamiento.

Hasta que se aplique la actualización, puedes bloquear los métodos de escritura al punto final del formateador en el proxy inverso, bloqueando así las cargas legítimas de formateadores a través de la consola de administración.

El aviso enumera las siguientes reglas provisionales:
* Apache httpd - denegar solicitudes POST, PUT y PATCH a la ubicación /geonetwork/srv/api/formatters.
* Nginx - restringir la misma ubicación a los métodos GET, HEAD y OPTIONS.

Los fallos fueron corregidos aproximadamente ocho semanas antes de que se publicaran los avisos. Hasta el momento de la divulgación, no se encontró ninguna referencia a los fallos de GeoNetwork en el catálogo de Vulnerabilidades Explotadas Conocidas de CISA, ni informes públicos de explotación activa.

Esta revelación sigue una serie de problemas de seguridad en todo el ecosistema geoespacial. El año pasado, un fallo crítico de GeoServer (CVE-2024-36401, puntuación CVSS: 9.8) fue explotado por botnets, mineros de criptomonedas y el backdoor SideWalk, y un fallo de Entidad Externa XML (XXE) de GeoServer (CVE-2025-58360) fue añadido al catálogo KEV de CISA en diciembre de 2025 tras evidencias de explotación activa. El mes pasado, una inyección SQL no autenticada independiente que llevaba a RCE en GeoServer, divulgada como un zero-day de GeoServer, comenzó a ser objeto de sondeos activos poco después de hacerse pública.

Fuente:
THN