CVE-2021-21342: XStream SSRF Vulnerability in Java Library

CVE-2021-21342 Overview

CVE-2021-21342 is a critical Server-Side Request Forgery (SSRF) vulnerability in XStream, a widely-used Java library for serializing objects to XML and back. The vulnerability exists in versions prior to 1.4.16 and allows attackers to manipulate the input stream during unmarshalling to inject malicious type information. When XStream processes this crafted input, it creates new object instances based on the attacker-controlled type data, which can be exploited to initiate arbitrary server-side requests to internal or external systems.

This insecure deserialization flaw is particularly dangerous because XStream is embedded in numerous enterprise applications and frameworks, including Apache ActiveMQ, Apache JMeter, and multiple Oracle products. The vulnerability enables attackers to bypass network security controls, potentially accessing internal services, cloud metadata endpoints, or other restricted resources that should not be reachable from external networks.

Critical Impact

Attackers can exploit this SSRF vulnerability to forge server-side requests, potentially accessing internal services, exfiltrating sensitive data, or pivoting to attack internal network infrastructure from compromised XStream-enabled applications.

Affected Products

• XStream versions prior to 1.4.16
• Apache ActiveMQ (versions 5.16.0, 5.16.1, and prior)
• Apache JMeter (all versions using vulnerable XStream)
• NetApp OnCommand Insight
• Debian Linux 9.0, 10.0, and 11.0
• Fedora 33, 34, and 35
• Oracle Banking Enterprise Default Management 2.10.0 and 2.12.0
• Oracle Banking Platform 2.4.0, 2.7.1, 2.9.0, and 2.12.0
• Oracle Banking Virtual Account Management 14.2.0, 14.3.0, and 14.5.0
• Oracle Business Activity Monitoring 11.1.1.9.0, 12.2.1.3.0, and 12.2.1.4.0
• Oracle Communications BRM - Elastic Charging Engine 12.0.0.3
• Oracle Communications Policy Management 12.5.0
• Oracle Communications Unified Inventory Management 7.3.2 through 7.4.1
• Oracle Retail XStore Point of Service 16.0.6, 17.0.4, 18.0.3, and 19.0.2
• Oracle WebCenter Portal 11.1.1.9.0, 12.2.1.3.0, and 12.2.1.4.0

Discovery Timeline

• March 23, 2021 - CVE-2021-21342 published to NVD
• May 23, 2025 - Last updated in NVD database

Technical Details for CVE-2021-21342

Vulnerability Analysis

The vulnerability stems from XStream's handling of type information embedded within serialized XML streams during the unmarshalling process. XStream dynamically instantiates objects based on type metadata contained in the XML input, trusting this information to reconstruct previously serialized objects. However, this design creates a significant security gap when processing untrusted input.

An attacker can craft malicious XML payloads containing carefully constructed type hierarchies that, when deserialized, trigger unintended HTTP or other network requests from the server. This is a classic insecure deserialization pattern (CWE-502) that leads to Server-Side Request Forgery (CWE-918).

The attack does not require authentication and can be executed remotely against any application that processes untrusted XML through XStream. The impact includes potential access to internal network resources, cloud metadata services (such as AWS IMDSv1 at 169.254.169.254), and other services that trust requests originating from the application server.

Root Cause

The root cause lies in XStream's default security configuration, which relies on a blacklist approach to prevent dangerous object instantiations. This blacklist was insufficient to prevent all attack vectors, specifically failing to block gadget chains that could be leveraged for SSRF attacks.

XStream's deserialization mechanism processes embedded type information without adequately restricting which classes can be instantiated. When combined with specific Java classes available on the classpath that implement URL fetching or connection behaviors, attackers can construct gadget chains that initiate outbound network requests.

The fundamental issue is the reliance on blacklisting known dangerous types rather than whitelisting only explicitly allowed types, which is the recommended security posture for deserialization operations.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker must be able to submit crafted XML data to an endpoint that processes it using a vulnerable XStream instance.

The exploitation flow typically involves:

1. The attacker identifies an application endpoint that accepts XML input and uses XStream for deserialization
2. A malicious XML payload is crafted containing type information for classes that can trigger network requests
3. When the application deserializes the payload, XStream instantiates the specified objects
4. The object instantiation or subsequent method calls trigger HTTP requests to attacker-specified URLs
5. The server makes requests to internal or external targets, potentially returning sensitive data or enabling further attacks

The vulnerability is exploitable without any prerequisites beyond network access to a vulnerable endpoint. Applications using XStream's default blacklist configuration are vulnerable, while those implementing a strict whitelist of allowed types are protected.

Detection Methods for CVE-2021-21342

Indicators of Compromise

• Unexpected outbound HTTP/HTTPS connections from application servers to internal IP ranges (10.x.x.x, 172.16.x.x-172.31.x.x, 192.168.x.x)
• Connections to cloud metadata endpoints such as 169.254.169.254 from Java application processes
• Large or unusually structured XML payloads in application logs containing unfamiliar Java class references
• Application errors related to class instantiation failures or unexpected type conversion during XML processing

Detection Strategies

• Implement network monitoring to detect SSRF patterns such as connections to RFC 1918 addresses or link-local addresses from application servers
• Deploy web application firewall (WAF) rules to inspect incoming XML payloads for suspicious class references and deserialization gadget patterns
• Configure application logging to capture and alert on XStream deserialization errors or attempts to instantiate unexpected classes
• Use static application security testing (SAST) tools to identify XStream usage and verify security framework configuration

Monitoring Recommendations

• Enable verbose logging for XStream deserialization operations to capture attempted class instantiations
• Monitor outbound network traffic from Java application servers for anomalous connection patterns
• Implement egress filtering and log all denied outbound connections from application tier servers
• Deploy runtime application self-protection (RASP) solutions capable of detecting deserialization attacks

How to Mitigate CVE-2021-21342

Immediate Actions Required

• Upgrade XStream to version 1.4.16 or later, which addresses this vulnerability
• Implement XStream's security framework with an explicit whitelist limited to only the required types for your application
• Review and update all downstream dependencies that include XStream, including Apache ActiveMQ and Apache JMeter
• Apply vendor-specific patches from Oracle, Debian, Fedora, and other affected distributions

Patch Information

The XStream project released version 1.4.16 to address this vulnerability. Organizations should upgrade to this version or later as the primary remediation. The X-Stream Change Log documents the security fixes included in this release.

For Oracle products, security patches are available through the Oracle Critical Patch Update January 2022 and earlier CPU releases. Debian has released DSA-5004 addressing this issue. NetApp customers should refer to advisory NTAP-20210430-0002.

The GitHub Security Advisory GHSA-hvv8-336g-rx3m provides additional technical details about the vulnerability and fix.

Workarounds

• Configure XStream's security framework with a strict whitelist of allowed types rather than relying on the default blacklist
• Implement network egress controls to prevent application servers from initiating connections to internal resources or sensitive metadata endpoints
• Deploy input validation to reject XML payloads containing unexpected or suspicious type declarations before they reach XStream
• Consider using alternative serialization libraries that provide secure-by-default configurations for untrusted input processing

# Example XStream whitelist configuration in Java application startup
# Add to application configuration or security initialization code
# XStream xstream = new XStream();
# xstream.allowTypes(new Class[] { MyAllowedClass1.class, MyAllowedClass2.class });
# xstream.allowTypesByWildcard(new String[] { "com.mycompany.dto.**" });

# Verify XStream version in Maven dependencies
mvn dependency:tree | grep xstream
# Expected output for patched version: com.thoughtworks.xstream:xstream:jar:1.4.16 or higher