Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-09-03T18:17:22.827Z",
  "pubdate": "2026-09-03T18:17:22.827Z",
  "executiveSummary": "GeoNetwork versions prior to 4.4.12 and 4.2.17 are susceptible to an Arbitrary Command Execution vulnerability due to insecure configuration of the Saxon XSLT processor.\nThe vulnerability stems from the failure to enable FEATURE_SECURE_PROCESSING and the failure to disable ALLOW_EXTERNAL_FUNCTIONS within the XSLT transformation engine.\nAn attacker possessing sufficient privileges to upload custom formatters can execute arbitrary OS commands under the context of the GeoNetwork process user.\nThis represents a critical risk as it allows for full system compromise, unauthorized data access, and potential lateral movement within the hosting environment.\nExploitation requires authenticated access with permissions sufficient to manage or upload formatter files.",
  "technicalDetails": "The vulnerability resides in the configuration of the Saxon XSLT processor utilized by GeoNetwork to render formatters. Specifically, the processor is initialized without enforcing secure processing constraints.\nBy failing to set the FEATURE_SECURE_PROCESSING flag to true and neglecting to disable ALLOW_EXTERNAL_FUNCTIONS, the XSLT engine remains permissive to external Java extension functions. This configuration flaw allows XSLT stylesheets to bridge the gap between XML transformation and the underlying Java runtime environment.\nAn attacker with the ability to upload or define a formatter can craft a malicious .xsl file. Within this file, the attacker can define an XSLT transformation that invokes Java extension functions directly. By targeting sensitive classes such as java.lang.Runtime.exec() or java.lang.ProcessBuilder, the attacker can execute arbitrary operating system commands.\nThe attack flow follows these steps: 1. The attacker gains access to a GeoNetwork instance with privileges to upload or modify formatter configurations. 2. The attacker uploads a weaponized .xsl stylesheet containing the malicious extension function call. 3. Upon trigger of the formatter by the application or a user, the Saxon processor renders the XSLT file. 4. The processor processes the extension function, invoking the specified Java method. 5. The command executes with the permissions of the user account running the GeoNetwork application server.\nThis vulnerability effectively bypasses the intended functional scope of the XSLT engine, turning a content transformation feature into a remote command execution vector. The impact is severe, as the attacker achieves persistence and execution capabilities commensurate with the GeoNetwork application's service account privileges. Affected versions include all instances prior to 4.4.12 and 4.2.17."
}