Two vulnerabilities in GeoNetwork can be chained to achieve unauthenticated remote code execution (RCE) on the open-source geospatial metadata catalog, which sits behind many government and agency geoportals.
The project shipped fixes in versions 4.4.12 and 4.2.17 on July 8, 2026, and published the vulnerability details on August 31.
GeoNetwork originated at the United Nations Food and Agriculture Organization and is maintained under the Open Source Geospatial Foundation (OSGeo). It is a core component of many Spatial Data Infrastructure deployments across Europe and beyond, including the backend of the European INSPIRE geoportal.
The chain combines a missing authorization check with an unsafe transformation engine. The first flaw, CVE-2026-63219 (CVSS score: 8.6), is a missing authorization check on the formatter upload endpoint.
The unauthenticated file upload flaw allows an anonymous user to write arbitrary .xsl or .zip formatter files to the GeoNetwork formatter directory, which, on its own, constitutes unauthorized write access to server storage.
“An unauthenticated attacker can upload arbitrary .xsl or .zip formatter files to the server,” the project said in the advisory.
The second flaw, CVE-2026-58400 (CVSS score: 9.1), is an unsafe configuration of the Saxon Extensible Stylesheet Language Transformations (XSLT) processor used to render formatters.
The engine runs with secure processing enabled and Java extension functions disabled, so any stylesheet it loads can call java.lang.Runtime.exec() or java.lang.ProcessBuilder and run operating-system commands as the GeoNetwork process user.
On its own, that second flaw requires privileges to upload a formatter, which is why it is scored as needing high privileges. Chaining it with the upload flaw removes that precondition, because the upload is reachable without authentication.
An attacker first uploads a malicious formatter through the unprotected endpoint. A follow-up GET request to a public record then triggers the Saxon engine to execute the stylesheet, which delivers code execution. Security vendor Ethiack, whose researcher Rafael Castilho reported the flaws, said the chain is reachable starting with version 4.0.6, when the formatter endpoint was refactored, and the authorization line was dropped.
Ethiack said it fingerprinted 121 internet-exposed GeoNetwork deployments running affected versions across 39 countries, and that 89 percent of them were government-, military-, or national-agency-related.
Those figures describe exposed instances running vulnerable versions, not confirmed victims or compromises, and the fingerprinting is single-sourced to the vendor.
All 4.4.x releases up to and including 4.4.11 and all 4.2.x releases up to and including 4.2.16 are affected, and the flaws are fixed in 4.4.12 and 4.2.17.
“All users are strongly encouraged to upgrade to 4.4.12 or 4.2.17 as soon as possible,” the project said in its release announcement.
Until the update is applied, administrators can block write methods to the formatter endpoint at the reverse proxy, thereby blocking legitimate formatter uploads through the admin console.
The advisory lists the following interim rules –
- Apache httpd – deny POST, PUT, and PATCH requests to the /geonetwork/srv/api/formatters location.
- Nginx – restrict the same location to GET, HEAD, and OPTIONS methods.
The flaws were fixed roughly eight weeks before the advisories were published. The Hacker News found no reference to the GeoNetwork flaws in CISA’s Known Exploited Vulnerabilities catalog as of the disclosure, and no public reporting of exploitation in the wild.
The disclosure follows a run of security issues across the wider geospatial stack. Last year, a critical GeoServer flaw (CVE-2024-36401, CVSS score: 9.8) was exploited into botnets, cryptocurrency miners, and the SideWalk backdoor, and a GeoServer XML External Entity (XXE) flaw (CVE-2025-58360) was added to CISA’s KEV catalog in December 2025 after evidence of active exploitation. Last month, a separate unauthenticated SQL injection to RCE in GeoServer, disclosed as a GeoServer zero-day, came under active probing shortly after it went public.
