GeoNetwork Has an Unauthenticated RCE Problem — and Governments Are Exposed
- The Mess: Two GeoNetwork vulnerabilities can be chained into remote code execution without authentication. Researchers found 121 vulnerable Internet-exposed deployments across 39 countries, including government and military geoportals.
GeoNetwork is not some obscure developer toy.
The open-source geospatial metadata platform sits behind geoportals used by governments, national agencies and other public organizations. It originated at the United Nations Food and Agriculture Organization and is now maintained under the Open Source Geospatial Foundation.
That makes the newly disclosed attack chain particularly ugly.
The chain starts with CVE-2026-63219, an authorization flaw in the formatter upload API.
The endpoint doesn’t properly enforce authentication.
An attacker can therefore upload arbitrary .xsl or .zip formatter files directly to the server.
No account.
No password.
No victim interaction.
The vulnerability carries a CVSS score of 8.6.
On its own, unauthorized file upload is already bad.
Then comes CVE-2026-58400.
This one affects the Saxon XSLT processor used by GeoNetwork to process formatters.
Under certain conditions, a malicious stylesheet can invoke Java classes capable of executing operating-system commands, including java.lang.Runtime.exec() and java.lang.ProcessBuilder.
That vulnerability has a CVSS score of 9.1.
Put the two together and the authentication barrier disappears.
An attacker first uploads a malicious formatter.
Then they trigger its processing through a follow-up request.
The server executes the attacker’s commands with the privileges of the GeoNetwork process.
That’s the entire chain.
Upload code. Trigger code. Own server.
- The Damage: A remote attacker can potentially turn a publicly reachable government geoportal backend into a foothold for data theft, persistence, lateral movement or malware deployment.
Ethiack’s Internet scanning makes the exposure more uncomfortable.
Researchers identified 121 vulnerable GeoNetwork deployments across 39 countries.
Around 89% were associated with government, military or national-agency infrastructure.
The rest included academic institutions and businesses.
Those numbers do not mean 121 organizations were compromised.
They represent vulnerable Internet-exposed systems identified during fingerprinting.
There is also no confirmed exploitation in the wild reported at disclosure time.
That’s worth stating because the attack chain is nasty enough without inventing an active campaign.
The affected versions are:
- GeoNetwork 4.4.x through 4.4.11
- GeoNetwork 4.2.x through 4.2.16
The project fixed both vulnerabilities in:
- 4.4.12
- 4.2.17
The patches were released on July 8, while the vulnerability details became public on August 31.
There is another reason defenders should care.
GeoNetwork can sit behind infrastructure publishing geographic and environmental information.
That can include metadata describing public-sector datasets, mapping services and spatial resources.
Compromise of the backend therefore isn’t just a website-defacement problem.
An attacker gaining code execution can potentially use the server as a launch point into the surrounding environment.
And because the first step requires no credentials, the attack surface starts at the public Internet.
That’s exactly where defenders don’t want an upload endpoint sitting.
- The Fix: Upgrade immediately to GeoNetwork 4.4.12 or 4.2.17 and, until patching is complete, block POST, PUT and PATCH requests to
/geonetwork/srv/api/formattersat the reverse proxy.
GeoNetwork’s advisory provides temporary mitigation rules for both Apache and Nginx.
For Apache, administrators can deny write methods against the formatter endpoint.
For Nginx, the endpoint can be restricted to GET, HEAD and OPTIONS.
That will also break legitimate formatter uploads through the API, so it’s a mitigation — not a permanent fix.
After patching, administrators should investigate whether the vulnerable endpoint was exposed to the Internet and review server logs for suspicious formatter uploads.
Look for unexpected .xsl and .zip files.
Look for unusual requests against formatter-related endpoints.
And investigate unexpected child processes spawned by the GeoNetwork Java process.
If compromise is confirmed, don’t stop at upgrading the application.
The attacker may already have executed commands on the host.
Check persistence, credentials, SSH access, new users, scheduled tasks and outbound connections.
A patched server is not automatically a clean server.
Bugstoday Opinion
This one has an almost perfect attack chain.
No credentials. Upload a file. Trigger it. Execute commands.
No exotic memory corruption.
No browser exploit.
No social engineering.
Just a public API that forgot to enforce authorization, followed by an unsafe XSLT configuration.
And the target population makes it much more interesting than another random open-source RCE.
GeoNetwork sits behind infrastructure used by governments and national agencies.
Researchers found vulnerable instances in 39 countries.
That doesn’t mean attackers are already inside.
It means the Internet has already shown defenders where the doors are.
The good news is that the maintainers patched this before public disclosure.
The bad news is that thousands of organizations have a terrible habit of treating geoportals as “just websites.”
They’re not.
They’re servers.
They have credentials.
They have network access.
And now we know that some of them had a path from an unauthenticated HTTP request straight to OS command execution.
The map was public. The shell didn’t need to be.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
GeoNetwork — Security Advisory GHSA-mh22-prqr-vf42 / CVE-2026-63219
GeoNetwork — Security Advisory GHSA-x898-729x-cc3r / CVE-2026-58400
Ethiack — Technical Research on GeoNetwork Vulnerabilities
The Hacker News — GeoNetwork Fixes Unauthenticated RCE Chain Affecting Government Geoportal Backends
