GeoNetwork: Two Flaws Enable Unauthenticated RCE in Public Geoportals

An Attack Chain Targeting the Geospatial Backend

GeoNetwork has fixed two vulnerabilities that, when combined, allow an anonymous attacker to execute code on the server hosting a geoportal. Patches are available in versions 4.4.12 and 4.2.17, released on July 8, 2026. Technical details were published on August 31, 2026.

The attack chain combines an upload endpoint lacking proper authorization checks with an insecure configuration of the Saxon XSLT processor. The first flaw allows an attacker to place a malicious formatter on the server; the second turns that file into a mechanism for executing operating system commands.

The vulnerabilities are identified as:

• CVE-2026-63219, with a reported CVSS score of 8.6;
• CVE-2026-58400, with a reported CVSS score of 9.1.

The associated GitHub Security Advisories do not assign CVSS scores. These values come from journalistic reconstruction of the case.

GeoNetwork is an open-source catalog for geospatial metadata, originally developed at the United Nations Food and Agriculture Organization and maintained under the umbrella of the Open Source Geospatial Foundation (OSGeo). It is used as a backend component for spatial data infrastructures and public geoportals, including the European INSPIRE system.

Anonymous Upload Paves the Way for a Malicious XSLT File

The first flaw, CVE-2026-63219, affects the endpoint used to upload GeoNetwork formatters. Because authorization checks are missing, an unauthenticated user can submit files with an .xsl or .zip extension, which are then saved in the designated directory.

The issue is documented in advisory GHSA-mh22-prqr-vf42 and affects the following Maven packages:

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

The affected versions are:

• GeoNetwork 4.4.x through 4.4.11;
• GeoNetwork 4.2.x through 4.2.16.

Even without being chained with other flaws, the vulnerability allows unauthorized writing to the application’s storage. In this case, however, the uploaded content can subsequently be interpreted by a component capable of interacting with Java.

According to security vendor Ethiack, the chain may be traced back to the restructuring of the formatter endpoint introduced in version 4.0.6, when the authorization check was reportedly removed. The flaw was discovered by researcher Rafael Castilho.

For inventory and remediation activities, organizations should nevertheless rely on the version ranges confirmed by the advisories: the 4.4.x and 4.2.x branches up to the respective vulnerable versions listed above.

Saxon Turns the Formatter into a Command-Execution Vector

The second issue, CVE-2026-58400, lies in the way GeoNetwork configures Saxon, the processor used for XSLT transformations. A stylesheet processed on the server can access Java functions that can be used to create processes, including:

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

An attacker can therefore insert instructions into the formatter that launch operating system commands. The code runs with the privileges of the account managing the GeoNetwork process, which does not necessarily have administrative privileges on the system.

Advisory GHSA-x898-729x-cc3r identifies the following Maven package as affected:

org.geonetwork-opensource:gs-web-app

This vulnerability also affects GeoNetwork through 4.4.11 and through 4.2.16, while fixes are included in versions 4.4.12 and 4.2.17.

The described configuration has secure processing enabled and Java extensions disabled. Despite these settings, the formatter could still access the primitives required to execute commands.

On its own, CVE-2026-58400 requires the attacker to already have the ability to upload a formatter. CVE-2026-63219 removes precisely that prerequisite, making the full sequence accessible without credentials.

The attack unfolds in six steps:

1. a malicious XSLT formatter is submitted to the unprotected endpoint;
2. GeoNetwork saves the file in the formatter directory;
3. the attacker sends a GET request for a public record;
4. rendering the record triggers Saxon;
5. the XSLT stylesheet invokes Runtime.exec() or ProcessBuilder;
6. the command is executed by the backend with the privileges of the GeoNetwork service account.

A compromise could expose data, configurations, and credentials accessible to the application. The server could also become a foothold for lateral movement within the infrastructure hosting the Spatial Data Infrastructure.

Hundreds of Exposed Installations, but No Confirmed Victims

Ethiack reported identifying 121 exposed and vulnerable GeoNetwork deployments on the Internet, distributed across 39 countries. According to the same assessment, 89% of the instances identified through fingerprinting were associated with government bodies, military organizations, or national agencies.

These figures do not represent 121 compromises. They describe systems that were reportedly reachable and running vulnerable versions, based on a single vendor’s estimate.

No public evidence has been disclosed of the attack chain being exploited in real-world attacks. At the time of disclosure, CVE-2026-63219 and CVE-2026-58400 were also not listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog.

Their absence from KEV means that no CISA confirmation of active exploitation was available. It does not lessen the technical severity: the endpoint is remotely reachable, the first step requires no authentication, and execution can be triggered by requesting a public record.

Immediate Upgrade and Temporary Endpoint Blocking

The definitive fix is to upgrade GeoNetwork to one of the protected releases:

• 4.4.12 for installations on the 4.4.x branch;
• 4.2.17 for installations on the 4.2.x branch.

Organizations unable to apply the patch immediately should use a reverse proxy to block write operations to:

/geonetwork/srv/api/formatters

On Apache httpd, the following requests should be denied for this path:

• POST;
• PUT;
• PATCH.

On Nginx, the proposed mitigation is to allow only:

• GET;
• HEAD;
• OPTIONS.

The restriction also affects legitimate operations: administrators will be unable to upload formatters through the console while the block remains active.

No specific indicators of compromise are available. Investigations should focus on reverse-proxy and application logs, looking for uploads of .xsl or .zip files to the formatter endpoint.

GET requests for public records immediately following an upload also warrant attention. At the operating-system level, organizations should check for unusual processes, shells, or commands launched by the GeoNetwork service account.

GeoServer Precedents Already Added to the KEV Catalog

This case follows a series of vulnerabilities that have also affected GeoServer, another core component of geospatial infrastructures.

CVE-2024-36401, with a CVSS score of 9.8, enabled unauthenticated RCE through manipulated OGC parameters and the unsafe evaluation of XPath expressions. It affected GeoServer versions before 2.22.6 and GeoTools versions before 29.6; the listed GeoServer fixes also include versions 2.23.6, 2.24.4, and 2.25.2.

The vulnerability was added to CISA’s KEV catalog on July 15, 2024, with a remediation deadline of August 5, 2024 for U.S. federal agencies. CISA required agencies to apply the vendor’s mitigations or discontinue use of the product if those mitigations were unavailable. The flaw was linked to attacks carried out by botnets, cryptocurrency miners, and the SideWalk backdoor.

CVE-2025-58360, an XXE vulnerability with a CVSS score of 8.2, was also added to KEV. The flaw affected XML input submitted to the GetMap operation at /geoserver/wms and was fixed in GeoServer versions 2.25.6, 2.26.3, and 2.27.0.

CVE-2025-58360 has been listed in the catalog since December 11, 2025, with a federal remediation deadline of January 1, 2026. CISA required organizations to apply the vendor’s mitigations, implement the relevant BOD 22-01 measures for cloud services, or discontinue use when no countermeasures were available.

At the time of disclosure, there was no comparable public evidence of exploitation for GeoNetwork. The combination of anonymous upload functionality and server-side XSLT transformations nevertheless makes upgrading a priority, especially for geoportals directly exposed to the Internet.