CVE-2021-21350 Overview
CVE-2021-21350 is a critical insecure deserialization vulnerability affecting XStream, a popular Java library used to serialize objects to XML and back again. In XStream versions prior to 1.4.16, remote attackers can execute arbitrary code by manipulating the processed input stream. This vulnerability specifically targets applications that rely on XStream's default blacklist security mechanism rather than implementing a proper whitelist configuration.
The vulnerability allows unauthenticated remote attackers to achieve full system compromise through specially crafted XML payloads. Applications that deserialize untrusted XML data using vulnerable XStream versions are at significant risk, particularly those in enterprise environments processing external data.
Critical Impact
Remote attackers can execute arbitrary code on affected systems without authentication by sending maliciously crafted XML payloads to applications using vulnerable XStream versions.
Affected Products
- XStream versions prior to 1.4.16
- Apache ActiveMQ (versions 5.16.0 and 5.16.1)
- Apache JMeter
- Oracle WebLogic Server (versions 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0)
- Oracle Banking Platform (versions 2.4.0, 2.7.1, 2.9.0, 2.12.0)
- Oracle Communications Unified Inventory Management (versions 7.3.2 through 7.4.1)
- Oracle WebCenter Portal
- Oracle Business Activity Monitoring
- NetApp OnCommand Insight
- Debian Linux (versions 9.0, 10.0, 11.0)
- Fedora (versions 33, 34, 35)
Discovery Timeline
- 2021-03-23 - CVE-2021-21350 published to NVD
- 2025-05-23 - Last updated in NVD database
Technical Details for CVE-2021-21350
Vulnerability Analysis
This insecure deserialization vulnerability exists in XStream's XML processing mechanism. When XStream deserializes XML data, it instantiates Java objects based on the XML structure. An attacker can craft malicious XML that, when deserialized, triggers the instantiation of dangerous object types that execute arbitrary code during the deserialization process.
The core issue stems from XStream's default security configuration relying on a blacklist approach rather than a whitelist. The blacklist attempts to block known dangerous classes, but attackers can discover new gadget chains or bypass techniques that are not included in the blacklist. This design flaw means that even with security measures in place, determined attackers can find exploitation paths.
The vulnerability requires no authentication and can be exploited remotely over the network. Successful exploitation results in complete compromise of confidentiality, integrity, and availability of the affected system.
Root Cause
The root cause is XStream's reliance on a default blacklist-based security framework instead of requiring explicit whitelisting of allowed types. The blacklist approach is inherently flawed because:
- New gadget chains are continuously discovered that bypass existing blacklists
- The blacklist must be maintained and updated to block newly identified dangerous classes
- Complex object graphs can create unexpected instantiation paths
XStream's security framework was designed to allow restricting which types can be deserialized, but the default configuration uses blacklisting which is insufficient against sophisticated attacks. Applications that do not explicitly configure a whitelist limited to minimal required types remain vulnerable.
Attack Vector
The attack vector is network-based, requiring no privileges or user interaction. An attacker crafts a malicious XML payload containing references to Java classes that, when instantiated during deserialization, execute attacker-controlled code. This is commonly achieved through gadget chains - sequences of method calls that ultimately lead to code execution.
The attacker sends the malicious XML to an endpoint that processes XML data using a vulnerable XStream instance. When XStream deserializes the payload, it instantiates the malicious object graph, triggering the code execution chain. The attack complexity is low as pre-built payloads and tools exist for generating malicious XStream payloads.
Typical exploitation scenarios include:
- Web applications accepting XML input for data import/export
- Message queuing systems processing serialized messages
- API endpoints parsing XML requests
- Configuration management systems loading external configurations
Detection Methods for CVE-2021-21350
Indicators of Compromise
- Unusual XML payloads containing references to dangerous Java classes such as java.lang.ProcessBuilder, java.lang.Runtime, or reflection-based classes
- Unexpected process spawning from Java application processes
- Network connections to unusual external hosts originating from application servers
- Log entries showing deserialization errors or class loading attempts for unexpected types
- Outbound connections on non-standard ports from web application contexts
Detection Strategies
- Monitor application logs for XStream deserialization errors or warnings about blocked types
- Implement network intrusion detection rules to identify malicious XML payloads containing known gadget chain classes
- Use application-level logging to track all incoming XML payloads for forensic analysis
- Deploy web application firewalls (WAF) with rules to detect XStream-specific exploitation patterns
- Implement runtime application self-protection (RASP) to monitor deserialization operations
Monitoring Recommendations
- Enable verbose logging for XStream security framework events to detect blocked deserialization attempts
- Monitor system process trees for unexpected child processes spawned by Java applications
- Configure alerting for any new outbound network connections from application servers
- Implement file integrity monitoring on application directories to detect dropped payloads
- Review authentication logs for patterns indicating reconnaissance or exploitation attempts
How to Mitigate CVE-2021-21350
Immediate Actions Required
- Upgrade XStream to version 1.4.16 or later immediately
- Implement XStream's security framework with a strict whitelist of allowed types
- Audit all applications using XStream to identify vulnerable deployments
- Apply vendor patches from Oracle, Apache, NetApp, and other affected vendors
- Restrict network access to applications processing XML data to trusted sources only
Patch Information
The primary mitigation is upgrading to XStream version 1.4.16 or later, which addresses this vulnerability. For detailed patch information, refer to the X-Stream Changes Log and the GitHub Security Advisory.
Oracle has released patches addressing this vulnerability in multiple products through their Critical Patch Updates. Refer to the Oracle Security Alert January 2022 and Oracle Security Alert October 2021 for product-specific patches.
For Debian-based systems, apply updates per the Debian Security Announcement. NetApp users should consult the NetApp Security Advisory.
Workarounds
- Configure XStream's security framework with a whitelist limited to only the minimal required types for your application
- Implement input validation to reject XML payloads containing references to dangerous class patterns
- Deploy network segmentation to isolate systems processing untrusted XML data
- Use a Web Application Firewall to filter requests containing known malicious XStream payloads
- Consider alternative serialization libraries that provide safer defaults if upgrading is not immediately possible
// XStream whitelist configuration example
XStream xstream = new XStream();
// Clear all permissions first
xstream.addPermission(NoTypePermission.NONE);
// Only allow specific types your application needs
xstream.addPermission(NullPermission.NULL);
xstream.addPermission(PrimitiveTypePermission.PRIMITIVES);
xstream.allowTypes(new Class[] { YourAllowedClass.class });
xstream.allowTypesByWildcard(new String[] { "com.yourcompany.model.**" });
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

