“Ethiack said it fingerprinted 121 internet-exposed GeoNetwork deployments running affected versions across 39 countries, and that 89 percent of them were government-, military-, or national-agency-related.”
CVE-2026-63219 and CVE-2026-58400: a two-step path to unauthenticated RCE
Two distinct flaws in GeoNetwork, when combined, permit unauthenticated remote code execution (RCE) against the open-source geospatial metadata catalog used behind many government and agency geoportals. The first, CVE-2026-63219 (CVSS 8.6), is a missing authorization check on the formatter upload endpoint that allows anonymous users to write .xsl or .zip formatter files to the server’s formatter directory. “An unauthenticated attacker can upload arbitrary .xsl or .zip formatter files to the server,” the project advisory states.
The second, CVE-2026-58400 (CVSS 9.1), is an unsafe configuration of the Saxon XSLT processor that renders formatters. According to the advisory, the engine runs with secure processing enabled and Java extension functions disabled, yet any stylesheet it loads can call java.lang.Runtime.exec() or java.lang.ProcessBuilder and execute operating-system commands as the GeoNetwork process user. On its own that processor misconfiguration requires privileges to upload a formatter, but when chained with the unauthenticated upload flaw the requirement drops: an attacker can upload a malicious formatter and then trigger its execution by requesting a public record, yielding execution as the GeoNetwork process user.
Who reported it, when fixes shipped, and which versions are affected
The chain was reported by security vendor Ethiack; researcher Rafael Castilho is named in the disclosure. The GeoNetwork project shipped fixes in versions 4.4.12 and 4.2.17 on July 8, 2026, and published the vulnerability details on August 31, 2026. The project also notes that the chain is reachable starting with version 4.0.6, when the formatter endpoint was refactored and an authorization line was dropped.
All 4.4.x releases up to and including 4.4.11 and all 4.2.x releases up to and including 4.2.16 are affected. The project’s release announcement urges, “All users are strongly encouraged to upgrade to 4.4.12 or 4.2.17 as soon as possible.” The advisory also records that the flaws were fixed roughly eight weeks before the advisories were published.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildExposure snapshot: 121 internet-facing instances, many tied to government
Ethiack’s fingerprinting identified 121 internet-exposed GeoNetwork instances running affected versions across 39 countries; the vendor reported that 89 percent of those instances were government-, military-, or national-agency-related. The vendor’s numbers describe exposed instances running vulnerable versions and do not claim confirmed compromises; the fingerprinting is single-sourced to Ethiack.
GeoNetwork itself traces origin to the United Nations Food and Agriculture Organization and is maintained under the Open Source Geospatial Foundation (OSGeo). The project is a core component of many Spatial Data Infrastructure deployments across Europe and beyond, including the backend of the European INSPIRE geoportal—placing some sensitive public-sector assets in the population of potentially affected systems.
Immediate mitigations: upgrades and reverse-proxy workarounds
The straightforward fix is to upgrade to GeoNetwork 4.4.12 or 4.2.17. For administrators unable to upgrade immediately, the advisory provides interim reverse-proxy rules to block unauthenticated uploads to the formatter endpoint. The suggested measures are:
- Apache httpd: deny POST, PUT, and PATCH requests to /geonetwork/srv/api/formatters.
- Nginx: restrict the location /geonetwork/srv/api/formatters to GET, HEAD, and OPTIONS methods.
Blocking write methods at the reverse proxy prevents legitimate—and malicious—formatter uploads through the admin console until an update is applied.
What this means for technologists, procurement leaders, and government agencies
Technologists and security teams: patch to 4.4.12 or 4.2.17 where feasible, or apply the reverse-proxy mitigations immediately; validate that public record access does not inadvertently trigger newly uploaded formatters. Ethiack’s fingerprinting suggests internet-facing instances are discoverable and that chaining is practical on affected versions back to 4.0.6.
Procurement and acquisition leaders: the advisory underlines that a widely used open-source component—originating at the UN FAO and maintained under OSGeo—sits behind many public geoportals. Contract and supply-chain reviews should reflect the operational impact of vulnerabilities in upstream open-source components and the need for timely maintenance windows.
Government, military, and national agencies: with 89 percent of identified exposed instances tied to public authorities in Ethiack’s scan, agencies should inventory GeoNetwork deployments, confirm versioning, and prioritize either the update or the proxy-based containment steps.
Recent geospatial security context
The disclosure arrives amid a run of security issues in the geospatial software stack. The advisory notes a critical GeoServer flaw (CVE-2024-36401, CVSS 9.8) that was previously exploited into botnets, cryptocurrency miners, and the SideWalk backdoor; a GeoServer XXE flaw (CVE-2025-58360) that was added to a national KEV catalog in December 2025 after evidence of active exploitation; and a recent unauthenticated SQL injection to RCE in GeoServer that went under active probing shortly after disclosure. As of this disclosure, The Hacker News found no reference to the GeoNetwork flaws in CISA’s Known Exploited Vulnerabilities catalog and no public reporting of exploitation in the wild.
GeoNetwork administrators and public-portal operators now face a tight window: apply the supplied patches or put the reverse-proxy rules in place, and verify that no legacy instances remain reachable. The chain is straightforward, the fixes were available on July 8, and the advisory leaves a clear checklist—yet the discovery that 121 internet-exposed instances exist suggests the practical work of closing this gap will be both technical and organizational.
