GeoNetwork EUVD-2026-70647

No special conditions are required: the formatter upload API endpoint is exposed by default on any GeoNetwork installation in the affected version range, and exploitation requires only network access to the HTTP(S) port - no authentication, no specific user interaction, and no non-default configuration. The primary limiting factor for full RCE (beyond the write-access impact) is that the uploaded malicious formatter must be applied/processed by the GeoNetwork XSLT engine, which occurs when a user or automated job renders a metadata record using that formatter. Attackers who cannot control formatter application can still achieve persistent unauthorized write access to the server filesystem as a standalone impact. Scope is limited to GeoNetwork instances accessible from the attacker's network; instances behind authenticated proxies or restricted to internal VPN would reduce exposure.

The provided CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N scores 8.6, reflecting unauthenticated network exploitation with a scope change but limiting impact to integrity (file write). This understates real-world risk: the XSLT-to-RCE chain elevates effective impact to C:H/I:H/A:H, a full server compromise. The scope change (S:C) in the vendor vector already signals that secondary system components are affected, consistent with XSLT-driven code execution escaping the web application context. EPSS data is not provided in the input; KEV status is not confirmed by CISA at time of analysis. No public exploit code was identified in the source data, but the technique (Java XSLT extension function injection) is publicly documented and the exploitation barrier is extremely low: a single unauthenticated HTTP multipart POST suffices to plant the payload. Hacker News coverage using 'RCE' in the headline is a strong corroborating signal. The straightforward nature of the exploit chain and the AC:L/PR:N conditions make this a real priority for any exposed GeoNetwork deployment, not merely a high-CVSS paper risk.

An attacker sends an unauthenticated HTTP multipart POST to the GeoNetwork formatter upload endpoint, supplying a malicious .xsl file containing XSLT extension function calls that invoke Runtime.exec() or equivalent Java APIs to run OS commands. The XSLT is accepted and written to the formatter directory without authentication checks. When any user - or an automated process - applies the formatter to view a metadata record, GeoNetwork's Java XSLT engine processes the stylesheet and executes the embedded system commands, granting the attacker code execution as the GeoNetwork service account. No specific public exploit code for this CVE has been confirmed, but the XSLT-to-Java-RCE technique is widely documented and trivially reproducible.