XStream is vulnerable to an Arbitrary Code Execution attack

Vulnerability

XStream versions 1.4.17 and earlier [1][2] deserialize XML input by recreating objects based on type information contained in the stream. When used out of the box with Java runtime version 14 to 8 or with JavaFX installed [1][2], the unmarshalling process does not restrict allowed types, enabling an attacker to inject objects that lead to arbitrary code execution. No user is affected who followed the recommendation to set up XStream's security framework with a whitelist limited to minimal required types [1][2].

Exploitation

An attacker only needs to manipulate the processed input stream fed to XStream's unmarshalling function [1][2]. No authentication or special network position beyond the ability to supply malicious XML data is required. The attack involves replacing the content of a serialized object, such as a java.util.PriorityQueue, with crafted XML that references gadget classes like com.sun.java.util.jar.pack.PackageWriter$2 and com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl to trigger code loading from a remote server [2].

Impact

Successful exploitation allows a remote attacker to load and execute arbitrary code from a remote host [1][2]. This results in full compromise of the confidentiality, integrity, and availability of the affected application, as the attacker gains code execution within the context of the XStream library user process.

Mitigation

XStream version 1.4.18 removes the default blacklist and requires users to explicitly configure a whitelist of permitted types [1][2]. Users should upgrade to 1.4.18 or later and follow the security framework recommendation [1][2]. No fix is available for those who cannot upgrade; they must restrict allowed types manually. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog as of the publication date.