Security reporting cutoff: September 2, 2026, 11:18 a.m. EDT (15:18 UTC).
GeoNetwork disclosed two vulnerabilities that can be chained to produce unauthenticated remote code execution. The first permits an anonymous formatter upload; the second allows a sufficiently privileged formatter uploader to reach unsafe XSLT processing and execute commands as the GeoNetwork process user.[1][2]
The chain matters because it changes the access boundary. CVE-2026-58400 is scored with high privileges required, but CVE-2026-63219 supplies the unauthenticated upload capability that Ethiack used to remove that normal prerequisite in its demonstrated chain.[1][2][4]
Organizations operating GeoNetwork metadata catalogs or geoportal backends should move supported 4.2.x systems to 4.2.17 and supported 4.4.x systems to 4.4.12. Both project advisories identify those patched releases, and GeoNetwork’s 4.4.12 notes strongly encourage users of earlier 4.4.x versions to update promptly.[1][2][3]
The two vulnerabilities
CVE-2026-63219: unauthenticated upload
CVSS 8.6 — High
GeoNetwork’s advisory says an unauthenticated attacker can upload arbitrary formatter files and write them into the server’s formatter directory.[1]
The advisory’s Maven package records list supported 4.2 releases through 4.2.16 and supported 4.4 releases through 4.4.11 as affected, with fixes in 4.2.17 and 4.4.12.[1]
CVE-2026-58400: unsafe XSLT processing
CVSS 9.1 — Critical
The project says its Saxon XSLT processor was configured without secure processing and without disabling Java extension functions, allowing a loaded stylesheet to execute operating-system commands as the GeoNetwork process user.[2]
The advisory lists the same affected supported branches and the same fixed releases: 4.2.17 and 4.4.12.[2]
Why the chain is more serious than either score alone
The individual CVSS vectors describe separate preconditions: the upload flaw is network reachable with no privileges, while the XSLT flaw normally requires high privileges.[1][2] Ethiack reports chaining them so the anonymous upload supplies the formatter needed to reach the unsafe processor, resulting in pre-authentication RCE.[4]
This does not mean every GeoNetwork server is exposed or compromised. Exposure depends on an affected version, reachability of the relevant application path, and the deployed controls. No victim compromise, data theft, outage, or threat-actor attribution is established by the reviewed sources.[6]
Immediate decision for server operators
Patch affected supported branches rather than relying on the standalone CVSS privilege field for CVE-2026-58400. Inventory authorized GeoNetwork deployments, identify the exact running version and package provenance, and prioritize internet-reachable metadata or geoportal backends.
- GeoNetwork 4.2.x: move to 4.2.17 or a later supported release.[1][2]
- GeoNetwork 4.4.x: move to 4.4.12 or a later supported release.[1][2][3]
- Older or custom branches: do not infer safety from a version not named in the supported package ranges; plan migration to a supported fixed line and validate compatibility under change control.
Temporary mitigation if patching cannot happen immediately
The upload advisory recommends blocking write methods to the formatter-upload endpoint at the reverse proxy until a patched release is deployed.[1] This is a service-impacting containment measure: authenticated administrators will also lose formatter-upload functionality through that endpoint until the application is patched.[1]
Apply that restriction only to systems you are authorized to administer, preserve the existing proxy configuration for rollback, test required read-only behavior, and replace the temporary control with the fixed application release as soon as practical.
Safe response checklist
- Inventory without broad scanning. Check only authorized or customer-owned systems. Record the running GeoNetwork version, deployment method, package/image provenance, public exposure, and reverse-proxy path.
- Preserve evidence before disruptive work. Retain application, reverse-proxy, authentication, process, and host telemetry according to the organization’s incident-response policy.
- Patch every running instance. Update supported branches to 4.2.17 or 4.4.12 or later, including containers, replicas, secondary regions, and stale workers.[1][2]
- Use the vendor mitigation only as a bridge. If the patch must wait, block formatter write methods at the reverse proxy and verify that legitimate formatter administration is intentionally unavailable.[1]
- Investigate suspicious activity separately. Unexpected formatter uploads, process execution, child processes, or outbound connections are triage signals—not proof by themselves. Preserve evidence and open an incident-response track rather than testing public exploit code on production.
- Verify the outcome. Confirm the fixed build is actually running, all replicas were replaced, temporary proxy restrictions match the plan, required service behavior still works, and logs remain stable after rollout.
Exploitation status
Neither CVE appeared in CISA’s Known Exploited Vulnerabilities catalog version 2026.09.01 during our cutoff check, and The Hacker News reported finding no public in-the-wild exploitation reporting as of disclosure.[5][6] KEV absence and lack of public reporting do not prove exploitation has never occurred.
What remains unknown
- How many internet-reachable GeoNetwork deployments remain on vulnerable versions after patched releases became available.
- Whether any production system has been compromised through this chain.
- Whether CISA or another authority will later classify either CVE as known exploited.
- Whether any The IT Guys-managed customer environment runs GeoNetwork; no customer data was accessed to prepare this article.
Bottom line
GeoNetwork operators should treat this as an urgent patch event: one flaw enables anonymous formatter upload, and the second turns a loaded formatter into command execution as the application process user. Upgrade supported 4.2.x systems to 4.2.17 and 4.4.x systems to 4.4.12 or later, use the documented reverse-proxy restriction only as a temporary bridge, and keep patching separate from any investigation of possible earlier access.