Nixpkgs security tracker

Try the new UI
Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Suggestion detail

Dismissed
(no matching packages found)
Permalink CVE-2026-58400
9.1 CRITICAL
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): High (H)
  • User Interaction (UI): None (N)
  • Scope (S): Changed (C)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): High (H)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Changed (C)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 1 week, 6 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
GeoNetwork vulnerable to Remote Code Execution via unsafe Saxon XSLT processor configuration in formatter

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.

Affected products

core-geonetwork
  • ==>= 4.3.0, < 4.4.12
  • ==< 4.2.17