CVE-2026-4813: Lutece Core XSL Module RCE Vulnerability

CVE-2026-4813 Overview

CVE-2026-4813 is a code injection vulnerability [CWE-94] in the Lutece Core XSL export management module through version 7.1.7. The flaw allows authenticated administrators to achieve remote code execution on the server. The XML/XSLT processing pipeline does not enable secure processing mode (FEATURE_SECURE_PROCESSING), which allows Java extension functions to be invoked from attacker-supplied XSL stylesheets. An administrator can upload a crafted XSL transformation file and trigger its execution during user export operations, resulting in arbitrary code execution in the context of the Lutece application.

Critical Impact
Authenticated administrators can execute arbitrary Java code on the server, leading to full compromise of the Lutece Core host and any data or systems it can reach.

Affected Products

Lutece Core XSL export management module versions up to and including 7.1.7
Deployments exposing administrator authentication to untrusted networks
Instances where administrator accounts are shared across multiple operators

Discovery Timeline

2026-09-01 - CVE-2026-4813 published to the National Vulnerability Database (NVD)
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-4813

Vulnerability Analysis

The Lutece Core XSL export module processes administrator-provided XSL stylesheets to transform XML data during user export operations. The underlying Java XML transformation API supports a security feature named FEATURE_SECURE_PROCESSING that constrains resource use and disables risky extensions. The affected module does not enable this feature. As a result, the XSLT engine accepts stylesheets that call Java extension functions through namespace URIs mapping to arbitrary classes. An authenticated administrator uploads a malicious .xsl file, then triggers a user export. During transformation, the engine resolves the extension namespace and invokes native Java methods supplied in the stylesheet. This produces arbitrary code execution inside the Lutece Java Virtual Machine (JVM) process.

Root Cause

The root cause is the absence of FEATURE_SECURE_PROCESSING on the TransformerFactory used by the export module. Without this feature, XSLT extension mechanisms remain enabled by default in common Java XSLT implementations. Combined with a workflow that accepts administrator-uploaded stylesheets, the module treats an executable artifact as configuration data.

Attack Vector

Exploitation requires an authenticated account with administrator privileges. The attacker uploads a crafted XSL file through the export management interface. The attacker then initiates a user export that references the malicious stylesheet. The XSLT processor executes the embedded Java extension function calls. Successful exploitation yields code execution as the Lutece service account. Refer to the INCIBE CERT Notice on Code Injection for additional advisory context.

No verified public proof-of-concept code is available. The vulnerability mechanism relies on standard XSLT extension function syntax invoking Java classes at transformation time.

Detection Methods for CVE-2026-4813

Indicators of Compromise

Unexpected .xsl files uploaded to the Lutece XSL export storage location, particularly files containing extension namespace declarations that reference Java classes such as xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime".
Child processes spawned by the Lutece JVM that do not match normal application behavior, for example sh, bash, cmd.exe, powershell.exe, or network utilities.
Outbound network connections initiated by the Lutece process to unfamiliar hosts following an administrator export action.

Detection Strategies

Audit administrator activity logs for XSL upload events followed by export operations within a short time window.
Inspect stored XSL files for extension function calls, xalan://, xmlns:java, or references to java.lang.Runtime, java.lang.ProcessBuilder, and javax.script.ScriptEngineManager.
Correlate JVM process telemetry with file writes to the XSL directory to detect abnormal transformation activity.

Monitoring Recommendations

Enable endpoint process monitoring on servers hosting Lutece to capture child process creation from the Java runtime.
Forward Lutece application logs, web server logs, and host process telemetry to a centralized data lake for correlation and retention.
Alert on modifications to files under the XSL export directory outside of approved change windows.

How to Mitigate CVE-2026-4813

Immediate Actions Required

Upgrade the Lutece Core XSL export management module to a version above 7.1.7 that enables FEATURE_SECURE_PROCESSING.
Restrict administrator access to the Lutece backend using network segmentation, VPN, or IP allowlisting.
Rotate credentials for all administrator accounts and enforce multi-factor authentication on the administrator interface.
Review the XSL export directory and remove any stylesheets that were not deployed by an authorized change.

Patch Information

Consult the INCIBE CERT Notice on Code Injection for vendor guidance and fixed version details. Apply the patched release provided by the Lutece project and validate that the transformation factory is configured with secure processing enabled.

Workarounds

If patching is not immediately possible, disable the XSL export management module or block administrator access to the export upload endpoint at the reverse proxy.
Enforce strict file validation on uploaded XSL files to reject stylesheets containing extension function declarations or external Java namespace references.
Run the Lutece JVM under a dedicated low-privilege service account with no shell, no write access outside required paths, and restricted outbound network access.

bash

# Configuration example: enforce secure XSLT processing in Java
# Set at JVM startup or in application initialization code
# TransformerFactory tf = TransformerFactory.newInstance();
# tf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
# tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "");
# tf.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, "");