Back to Info Hub GeoNetwork - PreAuth Remote Code Execution Share Link copied! Rafael Castilho Security Researcher Ethiack August 31, 2026 Geospatial metadata catalogs are one of those pieces of infrastructure that nobody talks about and quietly sit behind government open-data portals, environmental agencies, and enterprise GIS platforms, cataloging where things are and what is known about them. GeoNetwork is a widely used open-source geospatial metadata catalog and an OSGeo project. Originally developed at the UN's FAO, it has become a core component in many Spatial Data Infrastructure initiatives across Europe and beyond. If you've browsed a national or regional geoportal, there's a real chance GeoNetwork was helping serve the metadata underneath. Being used by government entities it was what interested me, so that interest turned into four separate findings : CVE-2026-63219 - Unauthenticated file upload via missing Authorization on formatter Upload Endpoint CVE-2026-55864 - Unauthenticated Server-Side Request Forgery in SLD Tool CVE-2026-57582 - Reflected XSS via unsanitized Javascript Sink CVE-2026-58400 - Remote Code Execution via unsafe Saxon XSLT processor configuration in formatter Let's get started! How GeoNetwork works Before we start, a quick tour of the bits that matter for this post. GeoNetwork is a Java / Spring web application. Under the hood, three concepts are going to keep coming back: Records Every piece of metadata is a record, identified by a UUID . Plenty of these are public by design and you read them anonymously. In any real-world instance, it is basically certain there's at least one public record lying around. The /srv API - Almost everything is exposed under a portal-scoped API, like GET /srv/api/records/{uuid}. You'll see this prefix everywhere. XSLT, everywhere. GeoNetwork renders and transforms metadata using XSLT stylesheets. The page layouts are XSLT. The “formatters” that turn a record into an HTML or text view are XSLT. This detail is going to matter soon. On the security side, role operations are guarded with Spring's @PreAuthorize annotation such as: The interesting question in this situation is always “what endpoint was forgotten?” GeoVulnerabilities Unauthenticated file upload via missing Authorization on formatter Upload Endpoint Admin endpoints are supposed to be guarded by @PreAuthorize. The controller that manages formatters is FormatterAdminApi . As the name tells, it's admin functionality, meaning it has functionalities like listing, downloading, deleting, updating formatter files and every single one of those operations is locked behind: Which is good, except the method that writes a brand-new formatter to disk : One line missing and now anonymous users can use the addFormatter method to upload their own formatters into the server. Funny enough, the endpoint was secure in GeoNetwork instances bellow 4.0.6 version, but with the re-facture of the endpoint on version 4.0.6 , the PreAuthorize line was forgotten. Remote Code Execution via unsafe Saxon XSLT Now, uploading an XSLT stylesheet is only interesting if that stylesheet later gets executed, and that’s where the Saxon-B library engine comes in. When the library processes the XSLT file into a XML file to then be rendered on the website, It processes the file carelessly enough to let a stylesheet do dangerous things. Let's check the engine. The engine is configured at common/src/main/java/org/fao/geonet/utils/Xml.java The ALLOW_­EXTERNAL_­FUNCTIONS is never set. Checking the documentation, it says : The default value is true. The setting false is recommended in an environment where untrusted stylesheets may be executed. That means a stylesheet is allowed to call directly Java Runtime, thus, allowing us to achieve remote code execution by uploading the following malicious XSLT: After uploading, we just need to trigger the formatter by visiting the record with a simple GET: We control both values. We know our formatter name, because we just uploaded it. And a public record UUID is trivially discoverable because GeoNetwork's own search API hands it over So the whole chain looks like this: The full attack chain: an unauthenticated POST uploads a malicious XSLT formatter, a follow-up GET triggers Saxon-B to execute it Collisions Sadly, my submission for this vulnerability ended up being a collision with another researcher. We ended up contacting each other and it was decided that we would be happy to share the credits of the vulnerability, as we both found the issue independently. So shout out to Brexard for finding this vulnerability, great researcher. Unauthenticated SSRF GeoNetwork ships an SLD (”Styled Layer Descriptor”) tool for building map styles. It lives at POST /api/tools/ogc/sld , and it takes a caller-supplied WMS server URL : That serverURL goes straight into SLDUtil.parseSLD(new URI(serverURL), ...) with no allowlist, no scheme check, no SSRF guard. And what does parseSLD do with it? It fires a server-si...