CVE-2026-58400 in GeoNetwork
Summary
by MITRE • 09/03/2026
GeoNetwork is a catalog application to manage spatially referenced resources. Prior to versions 4.4.12 and 4.2.17, the Saxon XSLT processor used to render formatters is configured without secure processing (`FEATURE_SECURE_PROCESSING`) and without disabling Java extension functions (`ALLOW_EXTERNAL_FUNCTIONS`). Any stylesheet loaded by GeoNetwork can therefore invoke `java.lang.Runtime.exec()` or `java.lang.ProcessBuilder` directly, achieving arbitrary command execution as the GeoNetwork process user. A user with sufficient privileges to upload a formatter can deliver a `.xsl` file containing Java extension call that execute arbitrary OS commands with the privileges of the GeoNetwork process. The issue is patched in GeoNetwork versions 4.4.12 and 4.2.17.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
GeoNetwork serves as a comprehensive catalog application designed to manage spatially referenced resources, facilitating the discovery and sharing of geospatial data across various platforms. A critical security vulnerability was identified within the Saxon XSLT processor component used by GeoNetwork for rendering formatters prior to versions 4.4.12 and 4.2.17. This flaw stems from an insecure configuration where the secure processing feature, specifically FEATURE_SECURE_PROCESSING, is not enabled, and Java extension functions are permitted through ALLOW_EXTERNAL_FUNCTIONS being set to true. In a properly secured environment, XSLT processors should operate in a restricted mode that prevents access to external resources and disables potentially dangerous language extensions such as Java or JavaScript within stylesheets. The absence of these safeguards creates a significant attack surface for remote code execution attacks against the application infrastructure.
The technical nature of this vulnerability allows any stylesheet loaded by GeoNetwork to invoke java.lang.Runtime.exec() or java.lang.ProcessBuilder directly. This capability effectively bypasses standard sandboxing mechanisms that are typically expected in XML processing contexts, allowing attackers to execute arbitrary operating system commands with the same privileges as the user account running the GeoNetwork process. The root cause lies in the configuration of the Saxon engine, which by default allows for extensive integration with Java APIs when not explicitly restricted. This misconfiguration means that an attacker does not need complex exploitation techniques or multiple chained vulnerabilities to achieve code execution; a single maliciously crafted XSL file is sufficient to trigger arbitrary command execution on the underlying host system.
From an operational perspective, this vulnerability poses severe risks including complete compromise of the server hosting GeoNetwork, unauthorized access to sensitive geospatial data stored in associated databases, and potential lateral movement within the internal network if the compromised account has broad permissions. An attacker with sufficient privileges to upload a formatter can deliver a .xsl file containing Java extension calls that execute arbitrary OS commands. This capability aligns closely with CWE-94 Improper Control of Generation of Code or Command, specifically indicating an injection flaw where untrusted data controls code execution. Furthermore, the exploitation technique maps directly to MITRE ATT&CK techniques such as T1059 Command and Scripting Interpreter for executing system commands via Java extensions, and potentially T1203 Exploitation for Client Execution if delivered through a client-side vector, though in this case it is primarily server-side execution.
Mitigation strategies must prioritize immediate patching to the fixed versions 4.4.12 or 4.2.17 as these releases address the insecure configuration of the Saxon XSLT processor. For organizations unable to upgrade immediately due to compatibility constraints, implementing strict input validation and access controls on formatter uploads is essential. Administrators should ensure that only trusted users have permission to upload custom formatters and consider restricting file types accepted by the application server. Additionally, running GeoNetwork with least-privilege principles can limit the impact of successful exploitation; ensuring the process runs under a dedicated service account with minimal OS permissions reduces the potential damage from arbitrary command execution. Regular security audits of third-party library configurations are also recommended to prevent similar misconfigurations in other components that rely on XML processing engines.