CVE-2024-31573

What it actually does

XMLUnit for Java before 2.10.0 can execute XSLT extension functions when performing XSLT transformations in its default configuration. If an application uses XMLUnit to transform XML with an attacker-controlled or otherwise untrusted stylesheet, the stylesheet may invoke Java extension functionality through the underlying XSLT processor. In vulnerable usage patterns, this can lead to arbitrary Java method invocation and potential operating-system command execution in the context of the running Java process. The practical impact is constrained by whether untrusted XSLT is accepted, the configured TransformerFactory/XSLT engine, runtime permissions, and application exposure; this is why the assigned severity and EPSS are low, and there is no known KEV listing or public exploit maturity reported.

Why it matters to the business

Organizations using XMLUnit in production or tooling workflows that process untrusted XSLT could face unauthorized code execution, data access, or tampering within the affected Java process. The most likely exposure is in applications, test harnesses, XML comparison services, CI/CD utilities, or document-processing pipelines that allow users or upstream systems to supply stylesheets. Because exploitation requires a specific unsafe integration pattern and no known exploitation is reported, this should be treated as a targeted dependency risk rather than a broad internet-scale emergency; however, any externally reachable service that accepts XSLT should be prioritized because successful exploitation could compromise application data or build/runtime infrastructure.

How an attack unfolds

An attacker first identifies an application or workflow that uses XMLUnit for Java before 2.10.0 to perform an XSLT transformation where the stylesheet is supplied by, influenced by, or retrieved from an untrusted source. The attacker crafts a malicious XSLT stylesheet that declares extension namespaces supported by the underlying Java XSLT engine, such as Xalan-style Java extension bindings. When the vulnerable XMLUnit transformation runs, extension functions are enabled by default, allowing the stylesheet to call Java methods that should not be reachable from untrusted transformation logic. Depending on the XSLT processor and runtime restrictions, the attacker may read environment details, access files available to the Java process, initiate outbound connections, or spawn operating-system processes. Successful exploitation produces activity that resembles suspicious child processes from a Java runtime, unexpected outbound network traffic, unusual XSLT parsing or transformation errors, and request or file artifacts containing Java extension-function references.

How to fix it

Upgrade XMLUnit for Java to version 2.10.0 or later. For source-based consumers, ensure the code includes the fixed commit b81d48b71dfd2868bdfc30a3e17ff973f32bc15b or a later trusted revision. Review all Java dependency manifests and lockfiles for XMLUnit artifacts, including transitive dependencies, and update affected packages consistently across build, test, and production images. As defense in depth, do not process untrusted XSLT stylesheets; only allow trusted, version-controlled stylesheets. Where transformations are required, configure the underlying TransformerFactory with secure processing and restrictive external-access settings, such as XMLConstants.FEATURE_SECURE_PROCESSING and empty ACCESS_EXTERNAL_DTD / ACCESS_EXTERNAL_STYLESHEET values where supported. Disable XSLT extension functions using processor-specific controls where available, sandbox transformation workloads, run Java services with least-privilege operating-system accounts, restrict outbound network access, and prevent sensitive files or credentials from being readable by the transformation process.

How to confirm the fix worked

Confirm that all deployed and build-time Java dependency trees resolve XMLUnit for Java to 2.10.0 or later, or to a source revision containing commit b81d48b71dfd2868bdfc30a3e17ff973f32bc15b. Use Maven, Gradle, SBOM, container, and artifact-repository scans to identify older XMLUnit versions, including transitive copies. Review code paths that call XMLUnit transformation features and verify that untrusted users cannot supply or modify XSLT stylesheets. Add a negative security test that attempts to use an XSLT Java extension function and confirm it is rejected or inert after the fix. Validate runtime hardening by checking TransformerFactory settings, external stylesheet access restrictions, and whether the Java process is prevented from launching unnecessary child processes or making unexpected outbound network connections.

Typical attack path

1. Find an application, API, batch job, CI/CD step, or XML-processing workflow that uses XMLUnit for Java before 2.10.0.
2. Confirm that the workflow accepts, imports, retrieves, or otherwise processes an XSLT stylesheet that can be influenced by an attacker.
3. Submit a crafted stylesheet containing Java/XSLT extension-function declarations and calls.
4. Trigger the XMLUnit transformation path so the stylesheet is compiled and executed by the underlying XSLT processor.
5. Use extension functions to invoke sensitive Java methods or create operating-system processes under the Java application account.
6. Perform follow-on actions such as reading accessible files, extracting secrets from the process environment, writing files, or making outbound connections.

How to detect it

To determine whether this was already exploited, focus on systems that both use XMLUnit for Java before 2.10.0 and process attacker-controlled XSLT. Review web, API gateway, reverse-proxy, object-storage, message-queue, and application logs for submitted or retrieved stylesheets containing Java extension-function syntax. Search request bodies, uploaded files, temporary directories, and processing queues for XSLT namespaces that reference Java, Xalan, Saxon extension mechanisms, or command-execution classes. Review Java application logs for TransformerFactory, Xalan, Saxon, or XMLUnit transformation exceptions around suspicious requests. Use EDR/process telemetry to identify Java processes spawning shells or utilities such as sh, bash, cmd.exe, powershell.exe, curl, wget, nc, ncat, python, perl, or openssl during XML transformation activity. Review network telemetry for unexpected outbound connections from Java XML-processing services shortly after XSLT submissions. Because there are no public reports of widespread exploitation or known threat actors for this issue, detection should be behavior- and artifact-based rather than relying on fixed malware indicators.

• xsl:stylesheet
• xsl:transform
• http://xml.apache.org/xalan/java
• xalan://
• java.lang.Runtime
• Runtime.getRuntime
• java.lang.ProcessBuilder
• ProcessBuilder
• javax.xml.transform.TransformerException
• TransformerFactory
• org.xmlunit.transform
• org.xmlunit.builder.Input.byTransforming
• extension-element-prefixes
• saxon:script
• cmd.exe /c
• /bin/sh -c
• powershell.exe
• curl http
• wget http
• nc -e
• ncat -e

What your security team should do

• Inventory all uses of XMLUnit for Java and prioritize externally reachable services, document-processing systems, XML comparison APIs, and CI/CD workflows that process user-supplied XML or XSLT.
• Upgrade affected XMLUnit dependencies to 2.10.0 or later, or a revision containing b81d48b71dfd2868bdfc30a3e17ff973f32bc15b.
• Treat any workflow that accepts untrusted XSLT as high risk even though the CVSS and EPSS are low; remove that capability or restrict it to trusted stylesheets.
• Harden XML transformation configuration by enabling secure processing, blocking external DTD/stylesheet access, and disabling extension functions with processor-specific settings where possible.
• Add detections for suspicious Java child processes, XSLT extension-function strings in requests or files, and unexpected outbound network activity from Java XML-processing services.
• Review recent application, reverse-proxy, EDR, and file-system telemetry for evidence of malicious stylesheet submission or Java-spawned shell/network utilities.
• Ensure Java services run with least privilege and do not have direct access to secrets, sensitive files, package-signing keys, or broad network egress unless required.