CVE-2024-47072

What it actually does

The flaw affects XStream when it is configured to deserialize untrusted input using the BinaryStreamDriver. A specially manipulated binary input stream can cause unbounded recursive processing, exhausting the Java call stack and triggering a java.lang.StackOverflowError. The expected outcome is denial of service: the affected request, worker thread, or entire application process may fail depending on how the application handles the error. The vulnerability does not provide confidentiality or integrity impact by itself and is not known to enable code execution.

Why it matters to the business

An unauthenticated remote attacker may be able to crash or destabilize services that accept attacker-controlled XStream binary serialized data, causing service outages, failed transactions, degraded availability, and operational incident response costs. The CVSS availability impact is high, but current public exploitation signals are limited: it is not in CISA KEV, is not associated with ransomware use, and has a relatively low EPSS score of about 2%. Because XStream is commonly embedded as a library inside larger Java applications, exposure may be indirect and should be assessed through software composition and application data-flow review rather than package presence alone.

How an attack unfolds

An attacker first identifies an application endpoint, message consumer, API, queue processor, or file-import path that accepts XStream binary serialized data from an untrusted source. If the application uses XStream with BinaryStreamDriver to parse that data, the attacker submits a malformed binary stream designed to drive recursive parsing until the Java stack is exhausted. The vulnerable XStream version throws a StackOverflowError rather than safely rejecting the manipulated stream. If the calling application does not catch and isolate this error, the parsing thread may die, the request handler may fail, or the application process/container may restart. Repeated submissions can create a sustained denial-of-service condition.

How to fix it

Upgrade XStream to version 1.4.21 or later. The upstream fix detects the manipulated binary input stream and raises InputManipulationException instead of allowing stack exhaustion; the referenced upstream fixed commit is e62d2eeea1a627e85caef287e76a9c09078c1798. If XStream is delivered through a platform or distribution package, apply the vendor-supplied fixed package; for Ubuntu 14.04 LTS chromium-browser packaging, the listed fixed version is 47.0.2526.73-0ubuntu0.14.04.1.1106. Where immediate upgrade is not possible, reduce exposure by preventing untrusted users from reaching BinaryStreamDriver-based deserialization paths, enforcing authentication and rate limits, rejecting unexpected binary serialized content, isolating parsing in bounded worker processes, and catching StackOverflowError around the XStream call path as a temporary mitigation only. Prefer avoiding deserialization of untrusted data entirely and use safer, schema-constrained formats where feasible.

How to confirm the fix worked

Confirm that deployed applications no longer include vulnerable XStream versions and resolve to XStream 1.4.21 or later at runtime, including shaded, bundled, or transitive copies inside application artifacts. Review code and configuration for use of com.thoughtworks.xstream.io.binary.BinaryStreamDriver and verify that any untrusted input paths using it have been upgraded or disabled. Run dependency scans against build manifests and deployed artifacts such as JAR, WAR, EAR, container images, and vendor bundles. In staging, submit malformed or fuzzed binary XStream input to relevant parsers and confirm the application rejects the input gracefully, logs InputManipulationException or an equivalent handled validation failure, and remains healthy without process restart or worker exhaustion. For operating-system packages, verify the installed vendor package version is at or above the fixed version listed by the distribution.

Typical attack path

1. Discover a Java application or service path that accepts serialized binary input, uploaded files, API payloads, queued messages, or inter-service data processed by XStream.
2. Confirm or infer that the application uses XStream with BinaryStreamDriver rather than XML-only or another safe parsing path.
3. Send a manipulated XStream binary stream to the exposed parser.
4. Trigger recursive parsing that exhausts the Java stack and raises java.lang.StackOverflowError.
5. Repeat requests or message submissions to keep workers crashing, saturate restart loops, or maintain service unavailability.

How to detect it

To determine whether exploitation was attempted, review application logs, Java exception logs, web/API gateway logs, message broker logs, container orchestration events, and process supervisor logs for crashes or restarts correlated with requests, uploads, or messages that trigger XStream binary deserialization. Focus on repeated java.lang.StackOverflowError entries with stack traces involving XStream binary stream parsing, abrupt JVM termination, servlet/request failures, worker thread deaths, container crash loops, and elevated 500-series responses from endpoints that accept serialized content. For queue-based systems, look for poison messages repeatedly retried or moved to dead-letter queues immediately before consumer crashes. Network indicators are application-specific because the malicious input is a binary stream and no universal byte pattern is reliable; use correlation between inbound payload processing and JVM stack overflow events. After patching, attempts may appear as handled InputManipulationException events rather than crashes.

• java.lang.StackOverflowError
• com.thoughtworks.xstream.io.binary.BinaryStreamDriver
• com.thoughtworks.xstream.io.binary.BinaryStreamReader
• com.thoughtworks.xstream.io.binary.Token$Formatter
• com.thoughtworks.xstream.XStream.fromXML
• com.thoughtworks.xstream.io.StreamException
• com.thoughtworks.xstream.io.InputManipulationException
• StackOverflowError while deserializing
• StackOverflowError: null
• CrashLoopBackOff
• Back-off restarting failed container
• Process exited with code 1
• Exception in thread

What your security team should do

• Inventory applications and third-party products that embed XStream, prioritizing externally reachable services, message consumers, file importers, and APIs that process serialized data.
• Upgrade XStream to 1.4.21 or later, or deploy vendor patches that include upstream commit e62d2eeea1a627e85caef287e76a9c09078c1798.
• Search codebases and runtime configurations for BinaryStreamDriver usage; prioritize remediation where the input source is user-controlled, partner-controlled, or internet-facing.
• Add compensating controls for any delayed upgrades: authentication, request-size limits, parser isolation, rate limiting, queue dead-lettering, and safe error handling around deserialization.
• Create monitoring for repeated StackOverflowError events, application restarts, pod/container crash loops, and spikes in failed deserialization requests.
• Treat exploitation as availability-impacting rather than data-theft by default, but investigate any co-occurring suspicious activity because DoS attempts may be used to distract from other intrusion activity.
• Because the vulnerability is not currently in KEV and has low EPSS, prioritize based on exposure: internet-facing or unauthenticated parsing paths should be fixed quickly; internal-only, authenticated, non-BinaryStreamDriver uses are lower priority.