CVE-2026-58400

GeoNetwork versions before 4.4.12 and before 4.2.17 run the Saxon XSLT processor used to render formatters without secure processing (FEATURE_SECURE_PROCESSING) and without disabling Java extension functions (ALLOW_EXTERNAL_FUNCTIONS), so any stylesheet the application loads can invoke Java methods directly. A user with sufficient privileges to upload a formatter can deliver a malicious .xsl file that calls java.lang.Runtime.exec() or java.lang.ProcessBuilder, achieving arbitrary operating system command execution with the privileges of the GeoNetwork process. An attacker therefore gains code execution on the server (CVSS 9.1, scope-changing, critical), although network reachability requires an account that can upload formatters. All GeoNetwork deployments on the 4.4 branch prior to 4.4.12 and the 4.2 branch prior to 4.2.17 are affected, and related reporting highlights government geoportal backends as a key exposed population. No public proof-of-concept or confirmed in-the-wild exploitation is known (not in CISA KEV; EPSS ~1.2% over 30 days), though related headlines describe a fixed unauthenticated RCE chain affecting government geoportals, suggesting the flaw may be reachable through a longer attack chain.

What to do: Upgrade GeoNetwork to 4.4.12 on the 4.4 branch or 4.2.17 on the 4.2 branch (or later). Until patched, restrict formatter upload privileges to trusted administrators only and audit existing uploaded .xsl formatter files for Java extension calls such as Runtime.exec or ProcessBuilder. Internet-exposed GeoNetwork instances, especially government geoportals, should be prioritized, and given the related unauthenticated RCE chain headline, review authentication and any chained entry points on affected servers.