CVE-2022-34169: Apache Xalan Java XSLT integer truncation enables bytecode execution

Automated analysis

Generated by VULONE's analysis model from the NVD record, CISA KEV and EPSS data on 18 September 2026. Confidence: high.

high priorityNetwork-reachable, no authentication or interaction required, code execution impact, and a very high EPSS score, though no KEV listing or confirmed in-the-wild exploitation is recorded.

What it is

Apache Xalan Java's XSLTC compiler mishandles integer truncation when processing malicious XSLT stylesheets, corrupting the generated Java class files. Because Xalan is repackaged inside many Java runtimes, the flaw reaches a very wide install base. Successful corruption lets an attacker inject and run arbitrary Java bytecode.

Impact

An attacker can execute arbitrary Java bytecode in the context of the application or runtime processing the stylesheet, giving code execution rather than just a crash. The CVSS vector shows high integrity impact with no confidentiality or availability impact recorded.

Attack surface

Reached over the network (AV:N) with no privileges (PR:N) and no user interaction (UI:N), per the CVSS vector. Any component that compiles attacker-supplied XSLT with Xalan, directly or through a bundled JDK/JRE copy, is exposed.

Exploitation

Not listed in CISA KEV and no ransomware use is documented, but EPSS is very high at 0.810 (99.6th percentile), indicating strong predicted exploitation activity. References include public advisories and patch notices, not a confirmed in-the-wild exploit.

What to do

• Update Apache Xalan-Java to 2.7.3 or later, and apply the corresponding JDK/JRE, Oracle, Debian, Fedora, NetApp and Azul vendor updates that carry the fix.
• Inventory all Java runtimes and applications that bundle or depend on Xalan, including repackaged copies inside OpenJDK and other JDKs, since patching the standalone library alone may not cover them.
• Do not process untrusted or user-supplied XSLT stylesheets; restrict stylesheet sources to trusted, reviewed content.
• Where XSLT processing is required, run it in a sandboxed or least-privilege JVM with restricted class loading and filesystem access.

Detection

• Monitor for XSLT stylesheet uploads or submissions to Java services and correlate with subsequent class loading or unexpected bytecode execution.
• Alert on Xalan/XSLTC compilation activity in application logs where stylesheets are not expected from external sources.
• Watch for anomalous child processes or outbound connections spawned by JVM processes that handle XSLT.
• Track unpatched Xalan versions across hosts and containers using software inventory or SBOM data.

This assessment is produced automatically and is not human-reviewed. Verify against the vendor advisory before acting on it.