GeoNetwork is catalogue software for geospatial metadata. It began at the UN Food and Agriculture Organization and is now a core component of Spatial Data Infrastructure across Europe, including the backend of the European INSPIRE geoportal.
Rafael Castilho of Ethiack found two flaws in it. Separately, neither is unauthenticated remote code execution. Together, they are.
The chain is the finding
CVE-2026-63219, CVSS 8.6, is a missing authorization check on the formatter upload endpoint. An unauthenticated attacker can upload arbitrary .xsl or .zip formatter files to the server. On its own that is unauthorised write access — bad, but not execution.
CVE-2026-58400, CVSS 9.1, is an unsafe configuration of the Saxon XSLT processor. Secure processing is enabled, but Java extension functions are not restricted, so any stylesheet Saxon loads can call java.lang.Runtime.exec() or java.lang.ProcessBuilder and run operating-system commands. On its own that requires the ability to get a stylesheet in front of the engine — which normally means privileges.
Put them together and the privilege requirement disappears. Upload a malicious formatter with no credentials, then issue a plain GET request against a public record to make Saxon load and execute it.
That is the whole attack: an anonymous upload, then a normal-looking read of a public page.
It is worth being precise about why this matters beyond the individual scores. Vulnerability triage is usually done per-CVE, and neither of these would top a queue on its own — an 8.6 write and a 9.1 that "requires privileges". The composition is what produces pre-auth RCE, and composition is exactly what per-CVE scoring does not represent.
Who is running it
Ethiack fingerprinted 121 exposed GeoNetwork deployments across 39 countries. 89% were government, military or national-agency related.
Those are exposed instances, not confirmed compromises — the distinction matters and Ethiack draws it.
But the population is the point. Geospatial metadata catalogues are not a consumer product; they are national infrastructure inventories, sitting in the part of government that publishes where things are. A code-execution foothold there is a foothold on a machine that, by design, indexes other systems.
Eight weeks between the fix and the advisory
Versions 4.4.12 and 4.2.17 shipped on 8 July 2026. The advisories were published on 31 August — roughly eight weeks later.
Affected are all 4.4.x through 4.4.11 and all 4.2.x through 4.2.16, with the issue reachable since 4.0.6. That is a long tail of versions.
The gap is defensible as coordinated disclosure — it gives operators time to update before the details are public. It is also not silent. The fix is in a public open-source repository from the day it lands, and anyone diffing releases can reconstruct what changed. An eight-week window protects the operators who patch promptly and nobody else.
Ethiack is the same lab behind the Rails Active Storage flaw, which had a comparable shape: a fix that is real, and a set of operators who have not applied it.
No evidence of exploitation
We checked the CISA KEV catalogue directly — 1,687 entries as of 1 September 2026 — and neither CVE appears, nor any other GeoNetwork entry. No public reporting describes exploitation either.
Say that plainly rather than letting the absence read as an omission: this is a disclosed, patched, unexploited-so-far chain against a government-heavy install base. That is the good version of this story, and it stays the good version only for as long as the patching goes faster than the reverse-engineering.
What to do
- Update to 4.4.12 or 4.2.17. They have been available since July.
- Check the formatter directory for .xsl or .zip files nobody uploaded deliberately. The upload is the first half of the chain and it leaves an artefact.
- Do not expose the catalogue to the internet if the deployment does not need to be public. Most of the 121 probably do; some certainly do not.
- Review Saxon configuration in anything else you run that processes XSLT from a source users can influence. The unsafe default here is not unique to GeoNetwork.
What is not established
- Whether any of the 121 exposed instances is compromised. Exposure was measured; nothing else was.
- How many total deployments exist. 121 is what internet fingerprinting found, not an install base.
- Whether the flaws were independently discovered. Only Ethiack is credited.
- Whether the chain works against every affected version, or only the configurations tested.
- What the INSPIRE geoportal itself runs. GeoNetwork is named as the backend; nothing published says which version, or whether it was ever vulnerable.