XStream Denial of Service via stack overflow

Root

Cause XStream before version 1.4.20 contains a vulnerability that can lead to a denial of service (DoS) via stack overflow. The issue stems from how XStream handles hash code computation for collections and maps (e.g., java.util.HashMap, java.util.HashSet) during XML unmarshalling. By crafting an XML input that creates deeply nested or self-referencing sets and maps, an attacker can force recursive hash calculation, exhausting the call stack and crashing the application [1][2].

Exploitation

No authentication is required; the attacker only needs to deliver a malicious XML payload to an application using XStream. The attack exploits the fact that XStream reconstructs objects based on type information in the input stream. A specifically crafted XML with multiple nested `` elements and self-references triggers an infinite or deep recursive hash evaluation [2]. The vulnerability affects all XStream versions prior to 1.4.19 inclusive [2].

Impact

Successful exploitation results in termination of the executing thread with a StackOverflowError, effectively causing a denial of service [1][3]. The attacker does not gain code execution or data access; the impact is limited to application availability.

Mitigation

XStream 1.4.20 addresses this by catching the stack overflow and raising an InputManipulationException instead [1][3]. Users unable to upgrade can apply workarounds: catch StackOverflowError in client code, set NO_REFERENCES mode if references aren't used, or deny specific collection types via the security framework [2][3]. Changing default implementations of java.util.Map and java.util.Set to TreeMap and TreeSet is possible when the application does not depend on hash-based ordering and all elements are comparable [3].