CVE-2021-21347 Overview
CVE-2021-21347 is an insecure deserialization vulnerability in XStream, a popular Java library used to serialize objects to XML and back again. In XStream versions prior to 1.4.16, a remote attacker can load and execute arbitrary code from a remote host by manipulating the processed input stream. This vulnerability affects applications that rely on XStream's default blacklist security mechanism rather than implementing a properly configured whitelist.
Critical Impact
Remote attackers can achieve arbitrary code execution on vulnerable systems by crafting malicious XML input, potentially leading to complete system compromise without requiring authentication.
Affected Products
- XStream versions prior to 1.4.16
- Apache ActiveMQ 5.16.0 and 5.16.1
- Apache JMeter (multiple versions)
- Oracle WebLogic Server 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0, and 14.1.1.0.0
- Oracle Banking Platform 2.4.0, 2.7.1, 2.9.0, and 2.12.0
- NetApp OnCommand Insight
- Debian Linux 9.0, 10.0, and 11.0
- Fedora 33, 34, and 35
- Oracle WebCenter Portal 11.1.1.9.0, 12.2.1.3.0, and 12.2.1.4.0
- Oracle Communications Unified Inventory Management 7.3.2 through 7.4.1
Discovery Timeline
- 2021-03-23 - CVE-2021-21347 published to NVD
- 2025-05-23 - Last updated in NVD database
Technical Details for CVE-2021-21347
Vulnerability Analysis
This vulnerability stems from insecure deserialization in XStream's XML processing functionality. When XStream deserializes untrusted XML input, it can be tricked into instantiating arbitrary Java classes and invoking methods on those objects. The vulnerability exists because XStream's default security configuration relies on a blacklist approach to block known dangerous classes, which can be bypassed using gadget chains that leverage classes not included in the blacklist.
The attack leverages Java's dynamic class loading capabilities combined with XStream's ability to reconstruct arbitrary object graphs from XML. An attacker can craft a malicious XML payload that, when deserialized, triggers a chain of method invocations ultimately resulting in remote code execution.
Root Cause
The root cause is CWE-434 (Unrestricted Upload of Dangerous File Type), which in this context manifests as the ability to load and execute arbitrary code through the deserialization process. XStream's default security framework uses a blacklist to prevent instantiation of known dangerous classes, but this approach is inherently flawed as new gadget chains can bypass the blacklist.
Applications that do not configure XStream's security framework with a whitelist of explicitly allowed types are vulnerable. The blacklist-based security model cannot anticipate all possible exploitation paths, making it insufficient for protecting against deserialization attacks.
Attack Vector
The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending a specially crafted XML payload to any endpoint that deserializes XML using a vulnerable XStream instance. The malicious XML contains serialized Java objects that form a gadget chain, ultimately allowing the attacker to:
- Load arbitrary classes from a remote host
- Execute arbitrary code within the context of the vulnerable application
- Potentially achieve full system compromise depending on application privileges
The exploitation does not require any prior access to the target system, making it particularly dangerous for internet-facing applications.
Detection Methods for CVE-2021-21347
Indicators of Compromise
- Unexpected outbound network connections from Java application processes to unknown external hosts
- Unusual XML payloads in application logs containing references to uncommon Java classes or nested object structures
- Evidence of arbitrary class loading or reflection-based method invocations in application audit logs
- Suspicious process spawning from Java application containers or JVM processes
Detection Strategies
- Implement application-layer firewall rules to inspect XML content for known XStream exploitation patterns and gadget chain class names
- Deploy network intrusion detection signatures to identify malicious serialized object payloads in HTTP traffic
- Enable verbose logging for XStream deserialization operations and monitor for attempts to instantiate classes outside the expected application scope
- Conduct regular dependency scanning to identify applications using vulnerable XStream versions
Monitoring Recommendations
- Monitor Java application memory and CPU usage for anomalies that may indicate exploitation attempts
- Implement centralized logging for all XML processing endpoints and configure alerts for unusual deserialization patterns
- Track network egress from application servers to detect potential callback connections to attacker-controlled hosts
- Review application dependencies and create an inventory of all components using XStream for prioritized patching
How to Mitigate CVE-2021-21347
Immediate Actions Required
- Upgrade XStream to version 1.4.16 or later immediately across all affected applications
- Configure XStream's security framework with a strict whitelist limited to the minimal required types for your application
- Audit all applications in your environment for XStream dependencies, including transitive dependencies
- Implement input validation to reject XML payloads from untrusted sources where possible
Patch Information
The vulnerability is addressed in XStream version 1.4.16 and later. Multiple vendors have released security updates addressing this vulnerability:
- Oracle addressed this in their Critical Patch Update January 2022 and previous CPU releases
- Debian released security advisories DSA-5004 and updates for affected versions
- Fedora released package updates for versions 33, 34, and 35
- NetApp released advisory NTAP-20210430-0002
For detailed patch information, refer to the XStream 1.4.16 Changes Document.
Workarounds
- Implement XStream's security framework with an explicit whitelist of allowed types using XStream.addPermission() to allow only minimal required types
- If upgrading is not immediately possible, configure XStream with XStream.setupDefaultSecurity() and add only the specific types your application requires
- Consider blocking or sanitizing XML input at the application perimeter to prevent malicious payloads from reaching XStream
- Isolate applications using XStream in restricted network segments to limit potential impact of exploitation
# Configuration example for XStream whitelist security
# Add to your Java application initialization code:
#
# XStream xstream = new XStream();
# xstream.addPermission(NoTypePermission.NONE);
# xstream.addPermission(NullPermission.NULL);
# xstream.addPermission(PrimitiveTypePermission.PRIMITIVES);
# xstream.allowTypes(new Class[] { YourClass.class });
# xstream.allowTypesByWildcard(new String[] { "com.yourcompany.dto.**" });
#
# Reference: https://x-stream.github.io/security.html#workaround
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


