2026-09-05 · view entry permalink →
CVE-2026-63219 / CVE-2026-58400, GeoNetwork opensource: chained unauthenticated formatter upload plus unsafe Saxon XSLT processing reaches unauthenticated RCE (CVSS 8.6 / 9.1)
GeoNetwork opensource, the open-source geospatial metadata catalog application deployed behind government open-data portals, environmental agencies and national geoportals; the European INSPIRE geoportal is named as a deployment (The Hacker News, 2026-09-02), carried two flaws that chain into unauthenticated remote code execution. CVE-2026-63219 (CVSS 8.6) is a missing-authorization defect on the formatter-creation API (POST /geonetwork/srv/api/formatters): the endpoint's admin-only access check was present and effective in GeoNetwork versions before 4.0.6, but was dropped during a refactor of the endpoint in 4.0.6 and never restored, so any unauthenticated caller can upload arbitrary .xsl or .zip "formatter" files straight into the server's formatter directory (GeoNetwork Security Advisory, 2026-08-31; Ethiack, 2026-08-31). CVE-2026-58400 (CVSS 9.1) is a second flaw in how GeoNetwork configures its Saxon XSLT processor: the engine runs without secure processing enabled and without disabling external functions, so any stylesheet GeoNetwork loads can invoke java.lang.Runtime.exec() or java.lang.ProcessBuilder directly (GeoNetwork Security Advisory, 2026-08-31). Chained, an attacker uploads a malicious .xsl formatter through the unauthenticated endpoint, then triggers it with an unauthenticated GET against any public record (the formatter name is already known to the attacker from the upload step, and a public record identifier is trivially discoverable through GeoNetwork's own search API) reaching code execution as the GeoNetwork process user (Ethiack, 2026-08-31). Researcher Rafael Castilho published a reverse-shell proof-of-concept against GeoNetwork 4.4.11. The vendor's own advisory and MITRE's CNA record both track the affected range as every 4.3.x/4.4.x release up to 4.4.11 plus every 4.2.x release up to 4.2.16, both fixed in 4.4.12 and 4.2.17 released 2026-07-08 (GeoNetwork GitHub Releases, 4.4.12); Ethiack's independent research states the missing-authorization defect itself was introduced earlier, in the 4.0.6 refactor, so any deployment running an unsupported 4.0.6–4.2.x-line release the vendor advisory does not enumerate should not assume it is unaffected. No source (the vendor's own advisories, the discovering researcher, or The Hacker News) reports confirmed in-the-wild exploitation of either flaw. Ethiack's own internet-wide scan identified 121 affected GeoNetwork 4.x deployments across 39 countries or regions, 89% of them government, military or national-agency related, with Europe and EU/international-facing deployments accounting for 77.7% of the dataset (Ethiack, 2026-08-31).
An unauthenticated attacker can upload arbitrary .xsl or .zip formatter files to the server.
Any stylesheet loaded by GeoNetwork can therefore invoke java.lang.Runtime.exec() or java.lang.ProcessBuilder directly, achieving arbitrary
As you may expect, we can chain the Unauthorised Upload vulnerability with the unsafe XSLT processing vulnerability and get unauthenticated Remote Code Execution.