Core Geonetwork
Monthly
Unauthenticated arbitrary file upload in GeoNetwork prior to versions 4.4.12 and 4.2.17 allows remote attackers to write malicious XSLT or ZIP formatter files directly to the server's formatter directory without any authorization check. Because GeoNetwork processes uploaded `.xsl` formatter files server-side via a Java XSLT engine when rendering metadata records, attackers can weaponize this upload into a remote code execution chain by embedding Java extension function calls within the XSLT payload. No public exploit has been confirmed at time of analysis, but The Hacker News coverage explicitly frames this as unauthenticated RCE, and the exploitation path (malicious XSLT to Java extension-function execution) is a well-documented Java attack technique.
Arbitrary OS command execution in GeoNetwork before 4.4.12 and 4.2.17 arises because the Saxon XSLT processor that renders formatters runs without FEATURE_SECURE_PROCESSING and with Java extension functions (ALLOW_EXTERNAL_FUNCTIONS) enabled. A user privileged enough to upload a formatter can supply a malicious .xsl stylesheet that invokes java.lang.Runtime.exec() or java.lang.ProcessBuilder, running commands as the GeoNetwork process user. No public exploit is identified at time of analysis, though the vendor GHSA advisory and public reporting describe the technique in detail.
Post-login redirect validation in GeoNetwork's OAuth2/OIDC and Keycloak SSO authentication filters can be bypassed to redirect authenticated users to attacker-controlled external sites, enabling phishing attacks. Versions 3.12.0 through 4.2.15 and 4.4.0 through 4.4.10 are affected across both supported and archived release lines. The bypass exploits the filter's failure to reject protocol-relative URLs (e.g., //evil.example.com) that Java treats as relative paths but browsers resolve as absolute external destinations; no public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.
Unauthenticated arbitrary file upload in GeoNetwork prior to versions 4.4.12 and 4.2.17 allows remote attackers to write malicious XSLT or ZIP formatter files directly to the server's formatter directory without any authorization check. Because GeoNetwork processes uploaded `.xsl` formatter files server-side via a Java XSLT engine when rendering metadata records, attackers can weaponize this upload into a remote code execution chain by embedding Java extension function calls within the XSLT payload. No public exploit has been confirmed at time of analysis, but The Hacker News coverage explicitly frames this as unauthenticated RCE, and the exploitation path (malicious XSLT to Java extension-function execution) is a well-documented Java attack technique.
Arbitrary OS command execution in GeoNetwork before 4.4.12 and 4.2.17 arises because the Saxon XSLT processor that renders formatters runs without FEATURE_SECURE_PROCESSING and with Java extension functions (ALLOW_EXTERNAL_FUNCTIONS) enabled. A user privileged enough to upload a formatter can supply a malicious .xsl stylesheet that invokes java.lang.Runtime.exec() or java.lang.ProcessBuilder, running commands as the GeoNetwork process user. No public exploit is identified at time of analysis, though the vendor GHSA advisory and public reporting describe the technique in detail.
Post-login redirect validation in GeoNetwork's OAuth2/OIDC and Keycloak SSO authentication filters can be bypassed to redirect authenticated users to attacker-controlled external sites, enabling phishing attacks. Versions 3.12.0 through 4.2.15 and 4.4.0 through 4.4.10 are affected across both supported and archived release lines. The bypass exploits the filter's failure to reject protocol-relative URLs (e.g., //evil.example.com) that Java treats as relative paths but browsers resolve as absolute external destinations; no public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.