CVE-2026-68497
Summary
by MITRE • 09/11/2026
jackson-databind binds a JSON string to a javax.xml.datatype.Duration or javax.xml.datatype.XMLGregorianCalendar field by passing the raw string verbatim to DatatypeFactory.newDuration(value) or newXMLGregorianCalendar(value) in CoreXMLDeserializers.Std._deserialize. These deserializers are registered by default with no opt-in, so a plain ObjectMapper or JsonMapper with no polymorphic typing and no special configuration reaches this path. The XML Schema lexical grammar permits numeric components of arbitrary length, which the JDK materializes through the native BigInteger(String) and BigDecimal(String) constructors, both quadratic in digit count. Because the digits sit inside a JSON string token rather than a JSON number token, jackson-core's StreamReadConstraints.maxNumberLength guard never applies; jackson's own NumberDeserializers call validateIntegerLength or validateFPLength before parsing a stringified number, but the XML datatype deserializer omits that pre-check. An unauthenticated attacker can therefore submit a single request of a few megabytes, such as a Duration value consisting of the letter P followed by several million digits and the letter Y, and force tens of seconds to several minutes of single-threaded CPU work; a handful of concurrent requests can saturate a server's worker threads. This affects com.fasterxml.jackson.core:jackson-databind from 2.0.0 before 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2, and tools.jackson.core:jackson-databind from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. Users should upgrade to 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability in question represents a significant Denial of Service risk within the Jackson Databind library, specifically affecting versions from 2.0.0 up to but not including 2.18.10, as well as subsequent major releases prior to their respective patch versions. This flaw arises from how the library handles deserialization of XML Schema datatype fields, namely javax.xml.datatype.Duration and javax.xml.datatype.XMLGregorianCalendar. When a JSON string is bound to these specific field types, Jackson delegates the parsing logic directly to the Java Development Kit’s DatatypeFactory methods newDuration or newXMLGregorianCalendar without performing any preliminary validation on the input length. This behavior is particularly dangerous because it occurs by default; no special configuration, polymorphic typing enablement, or opt-in mechanism is required for an attacker to trigger this code path. Consequently, even a standard ObjectMapper instance with minimal security configurations remains vulnerable to exploitation.
The core technical flaw lies in the quadratic time complexity of the underlying JDK constructors BigInteger and BigDecimal when parsing numeric strings of arbitrary length. The XML Schema lexical grammar allows for numeric components within duration or calendar values that can be extremely long. When Jackson passes these raw, unvalidated strings to the JDK, the resulting computational effort scales quadratically with the number of digits in the input string. This creates a classic ReDoS-like scenario but driven by arithmetic parsing complexity rather than regular expression backtracking. An attacker can craft a malicious JSON payload containing a duration value such as P followed by several million Y characters or similar numeric sequences, forcing the server to perform tens of seconds to several minutes of single-threaded CPU-intensive work per request.
This vulnerability is exacerbated by the fact that Jackson’s standard StreamReadConstraints maxNumberLength guard does not apply in this specific context. Typically, Jackson validates the length of number tokens during parsing through methods like validateIntegerLength or validateFPLength within its NumberDeserializers class. However, because these XML datatype deserializers receive a JSON string token rather than a native JSON number token, they bypass those protective checks entirely. The library fails to enforce any pre-check on the size of the input before delegating it to the JDK’s potentially expensive parsing routines. This oversight allows an unauthenticated attacker to submit relatively small payloads in terms of byte count but massive complexity in terms of digit length, effectively weaponizing a single request to consume significant server resources.
The operational impact of this vulnerability is severe, leading to potential service degradation or complete outage through resource exhaustion. A single malicious request can tie up a worker thread for an extended period due to the quadratic computational load. In environments handling concurrent traffic, even a handful of such requests from different sources can saturate the server’s available worker threads, preventing legitimate users from accessing services and causing a widespread Denial of Service condition. This affects not only direct API consumers but also any backend service that processes JSON data containing these specific XML datatype fields without additional sanitization layers.
To mitigate this risk, organizations must upgrade their Jackson Databind dependencies to the patched versions immediately. The affected ranges include com.fasterxml.jackson.core:jackson-databind from 2.0.0 before 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2, as well as tools.jackson.core:jackson-databind from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. Upgrading to versions 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2 resolves the issue by implementing appropriate input validation and length constraints for these specific deserialization paths. Until upgrades are applied, defensive measures such as WAF rules to limit JSON string lengths or custom serializers that enforce stricter parsing limits may provide temporary relief, though upgrading remains the definitive solution. This vulnerability is categorized under CWE-400 Uncontrolled Resource Consumption and aligns with ATT&CK technique T1496 Resource Hijacking, highlighting its nature as a resource exhaustion attack vector against application servers.