CVE-2022-34169

What it actually does

Apache Xalan-Java's XSLTC compiler has an integer truncation flaw when compiling specially crafted XSLT stylesheets. If a vulnerable application or Java runtime compiles attacker-controlled XSLT, the generated Java class file can be corrupted in a controlled way, allowing arbitrary Java bytecode to be executed inside the hosting JVM. The issue affects standalone Xalan-Java and repackaged copies bundled in Java runtimes such as Oracle JDK/JRE/OpenJDK, GraalVM, Azul Zulu, and downstream operating-system or appliance packages.

Why it matters to the business

A successful exploit can let an unauthenticated remote attacker run code with the privileges of the Java application that processes the malicious stylesheet. In business terms, this can lead to application takeover, unauthorized data modification, service manipulation, or pivoting into connected systems. The risk is highest for services that accept user-supplied XSLT, XML transformation templates, reporting templates, integration mappings, or plugin content. Although this is not currently listed in CISA KEV and no ransomware association is provided, the EPSS score is high, the vulnerability has been public for several years, and vulnerable copies may be hidden inside JDKs, application servers, appliances, or shaded Java dependencies.

How an attack unfolds

An attacker first identifies a Java-based service that performs XSLT transformations and can be influenced to compile an attacker-provided stylesheet. The attacker submits a malicious XSLT document crafted to trigger the XSLTC integer truncation during stylesheet compilation. During compilation, the vulnerable Xalan implementation emits a malformed Java class file in a way that allows attacker-controlled bytecode semantics. When the application loads or executes the generated translet class, the attacker's bytecode runs inside the JVM process. From there, the attacker can perform actions available to the application account, such as modifying application data, writing files, launching child processes if permitted, calling internal services, or establishing persistence through application-level mechanisms.

How to fix it

Upgrade Apache Xalan-Java to version 2.7.3 or later wherever it is used directly. Also update Java runtimes and vendor distributions that include repackaged Xalan copies, including Oracle JDK/JRE/OpenJDK, GraalVM, Azul Zulu, and Linux distribution packages. For vendor appliances or bundled products, apply the vendor-provided fixed release or security patch. Because fixed_versions were not supplied for each affected product, use vendor advisories and package repositories to identify the corrected build for each installed product. Inventory both explicit dependencies such as xalan.jar and transitive, shaded, or repackaged copies inside application archives and runtime images. As compensating controls, do not process untrusted XSLT stylesheets, allow only approved server-side stylesheets, disable user-uploaded transformation logic, isolate XML transformation workloads, run Java services with least privilege, and restrict file, process, and network access from the JVM. XML secure-processing flags and external entity restrictions are useful hardening measures but should not be treated as complete remediation for this flaw.

How to confirm the fix worked

Confirm that no deployed application includes Apache Xalan-Java earlier than 2.7.3. Check dependency manifests, SBOMs, Maven/Gradle dependency trees, container images, application server libraries, fat JARs, WAR/EAR files, and operating-system packages. Verify Java runtime versions against vendor security advisories because vulnerable Xalan code may be present under repackaged namespaces such as com.sun.org.apache.xalan.internal. Test application behavior to ensure untrusted users cannot submit, upload, reference, or modify XSLT stylesheets. Where scanning tools are used, validate that they inspect nested archives and shaded dependencies rather than only top-level package names. After patching, rerun dependency and container scans, confirm the runtime/library versions, and perform a functional XSLT transformation test using trusted stylesheets to ensure no service regression.

Typical attack path

1. Discover a Java application, API, integration service, document processor, reporting feature, or XML gateway that performs XSLT transformations.
2. Determine whether the service accepts or retrieves attacker-controlled XSLT stylesheets rather than only using trusted server-side stylesheets.
3. Craft a malicious XSLT stylesheet that triggers the Xalan-Java/XSLTC integer truncation during compilation.
4. Submit or cause the vulnerable service to process the stylesheet.
5. The vulnerable XSLTC compiler generates a corrupted Java class/translet.
6. The JVM loads and executes the generated class, resulting in attacker-controlled Java bytecode execution.
7. Use the privileges of the Java process to modify data, write files, invoke internal APIs, spawn commands where allowed, or pivot to other systems.

How to detect it

Look for evidence that a Java service processed attacker-controlled XSLT and then performed abnormal actions. Relevant sources include application logs, XML/XSLT processing logs, web/API access logs for upload or transformation endpoints, Java exception logs, EDR process telemetry, file creation events, container runtime logs, and network egress telemetry. Investigate requests containing XSLT constructs such as xsl:stylesheet, xsl:transform, xsl:template, or unusually large/complex stylesheets submitted to endpoints that transform XML or generate reports. On hosts, review temporary directories and application work directories for unexpected generated .class or .jar files, especially names associated with Xalan translets. Correlate Java process activity with child process execution, unexpected outbound connections, file writes outside normal application paths, or dynamic class loading. Also search for vulnerable exposure artifacts such as xalan-2.7.2.jar or older, but treat those as exposure indicators rather than proof of exploitation. There are no universal network or file IOCs for this vulnerability because payloads are attacker-defined and execution occurs inside the JVM.

• xalan-2.7.2.jar
• xalan-2.7.1.jar
• xalan-2.7.0.jar
• org.apache.xalan.xsltc.trax.TemplatesImpl
• com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl
• org.apache.xalan.xsltc.runtime.AbstractTranslet
• com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet
• org.apache.xalan.xsltc.trax.TransformerFactoryImpl
• com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
• xsl:stylesheet
• xsl:transform
• xsl:template
• XSLTC
• Translet
• /tmp/Translet
• /var/tmp/Translet

What your security team should do

• Prioritize internet-facing or partner-facing Java services that accept XML, XSLT, transformation templates, integration mappings, document conversion jobs, or reporting templates.
• Inventory standalone Xalan-Java dependencies and Java runtime distributions across applications, containers, appliances, and build pipelines.
• Upgrade Xalan-Java to 2.7.3 or later and apply current vendor Java runtime/security updates for Oracle, OpenJDK, GraalVM, Azul, Debian, Fedora, NetApp, and other affected products in use.
• Search for nested or shaded vulnerable copies inside fat JARs, WARs, EARs, application server lib directories, and container layers.
• Disable or tightly restrict user-supplied XSLT processing; allow only trusted, pre-reviewed server-side stylesheets.
• Run XML transformation services with least-privilege OS accounts, restricted filesystem access, restricted outbound network access, and process-execution controls.
• Review logs and telemetry for suspicious XSLTC compilation activity, unexpected translet class loading, child processes spawned by Java services, and newly written class/JAR files in temporary directories.
• Because the EPSS score is high despite no KEV listing, treat exposed untrusted-XSLT processing paths as urgent even if exploit maturity is not reported as weaponized.