CVE-2026-68497: CPU Denial of Service via XML Datatype Deserialization in FasterXML jackson-databind

The vulnerability resides within the com.fasterxml.jackson.databind.ext.CoreXMLDeserializers module of the FasterXML jackson-databind library. This component provides standard deserializers for core XML datatypes defined within the javax.xml.datatype package. Specifically, it handles the binding of JSON string representations to javax.xml.datatype.Duration and javax.xml.datatype.XMLGregorianCalendar target objects.

Under normal execution, applications rely on these deserializers to translate incoming serialized JSON data into structured Java XML structures. However, because Jackson treats these fields as strings rather than direct numeric entities during the initial tokenization phase, standard numeric length protections are not applied. This introduces a significant attack surface where unauthenticated remote requests can transfer massive, unfiltered payloads directly to core system components.

The resulting impact is classified under CWE-400 (Uncontrolled Resource Consumption). By exploiting this flaw, a remote attacker can saturate the hosting JVM's execution threads, leading to complete CPU resource exhaustion and an application-wide Denial of Service.

The underlying defect is a logical bypass of Jackson's built-in defense-in-depth mechanisms, compounded by algorithmic complexity limitations in standard JDK library classes. Jackson provides a protection mechanism, StreamReadConstraints.maxNumberLength (defaulting to 1,000 characters), designed to reject excessively long numerical values before they are parsed. This mechanism is only triggered when Jackson processes numeric JSON tokens.

Because XML duration and calendar properties are enclosed in double quotes within the JSON payload, Jackson parses them as VALUE_STRING tokens. This diverts the processing logic away from numeric deserialization constraints. Instead, the input is subject to maxStringLength, which is set to a default limit of 20,000,000 characters. Consequently, an attacker can pass megabytes of numeric digits inside a JSON string without triggering any initial parsing errors.

Once parsed as a string, CoreXMLDeserializers.Std._deserialize passes the raw value directly to DatatypeFactory.newDuration(value) or DatatypeFactory.newXMLGregorianCalendar(value). These standard JDK implementation classes process numeric sub-components by instantiating java.math.BigInteger or java.math.BigDecimal objects. Both of these JDK classes historically rely on parsing algorithms with quadratic $O(n^2)$ time complexity with respect to digit length. Processing strings containing millions of digits blocks the active JVM execution thread for minutes, leading to rapid thread-pool exhaustion.

Prior to the patch, the deserialization path in com.fasterxml.jackson.databind.ext.CoreXMLDeserializers immediately delegated the string parsing task to the native DatatypeFactory instance without performing size validation.

// Vulnerable Code Path
protected Object _deserialize(String value, DeserializationContext ctxt)
{
    switch (_kind) {
    case TYPE_DURATION:
        // Raw, unvalidated value passed directly to the JDK factory
        return _dataTypeFactory.newDuration(value);
    case TYPE_QNAME:
        return QName.valueOf(value);
    case TYPE_G_CALENDAR:
        // Raw, unvalidated value passed directly to the JDK factory
        return _dataTypeFactory.newXMLGregorianCalendar(value);
    }
}

The official patch mitigates this vulnerability by calling Jackson's internal StreamReadConstraints validators on the string length before attempting instantiation. The validation methods validateIntegerLength() and validateFPLength() enforce the default 1,000-character upper limit, which is sufficient for any legitimate date, time, or duration representation.

// Patched Code Path in CoreXMLDeserializers.java
protected Object _deserialize(String value, DeserializationContext ctxt)
{
    switch (_kind) {
    case TYPE_DURATION:
        // Validate length against integer constraints prior to JDK parsing
        ctxt.getParser().streamReadConstraints().validateIntegerLength(value.length());
        return _dataTypeFactory.newDuration(value);
    case TYPE_QNAME:
        return QName.valueOf(value);
    case TYPE_G_CALENDAR:
        // Validate length against floating point constraints prior to JDK parsing
        ctxt.getParser().streamReadConstraints().validateFPLength(value.length());
        return _dataTypeFactory.newXMLGregorianCalendar(value);
    }
}

By evaluating value.length() against these constraints, the application throws a deserialization exception early in the execution flow. This prevents the execution path from reaching the complex, resource-intensive algorithmic calculations in the JDK.

To exploit this vulnerability, an attacker must identify a web application endpoint that exposes a JSON interface mapping to a Java object that uses javax.xml.datatype.Duration or javax.xml.datatype.XMLGregorianCalendar fields. Because these endpoints are often exposed externally for API integration or form submissions, authentication is typically not required to reach the vulnerable deserialization code path.

The attacker crafts a payload containing a structured string with an extremely large sequence of numbers. In the case of a Duration target, the attacker formats the payload with the standard duration prefix (P), followed by several million digits, and terminates it with a time unit designator such as Y (Years).

{
  "duration": "P999999999999999999999999999999999999[... truncated 2,000,000 digits ...]99999999Y"
}

When standard Java web containers (e.g., Spring Boot running embedded Tomcat) process this request, a single HTTP worker thread is assigned to parse the JSON. When the parser reaches the duration field, the execution thread enters the JDK's quadratic string conversion loop, pinning the CPU core at 100% utilization. By sending a small batch of concurrent requests, an attacker can saturate all available worker threads, preventing the container from handling legitimate incoming traffic.

The potential impact of successful exploitation is a complete Denial of Service (DoS) of the targeted application. Because the vulnerability targets thread pools at the web container level, the entire application server becomes unresponsive, affecting all hosted services and endpoints, even those that do not use XML datatypes.

The CVSS v3.1 base score of 7.5 reflects this severe availability threat. Because exploitation requires no authentication, zero user interaction, and only standard HTTP requests, the attack complexity is classified as low.

While there is no unauthorized access to data (Confidentiality) or unauthorized modification of system files (Integrity), the ease with which a single system can be rendered completely non-functional makes this a high-priority risk. This is especially true for enterprise platforms and microservices that process large volumes of public API requests.

The primary remediation strategy is upgrading the jackson-databind dependency to a patched version. These releases introduce the length validation checks inside the CoreXMLDeserializers class, neutralizing the attack vector at the deserializer layer.

If upgrading dependencies is not immediately feasible, organizations should implement transport-layer request limitations. Configuring API Gateways, reverse proxies, or Web Application Firewalls (WAFs) to reject JSON payloads exceeding a reasonable maximum size (e.g., 50 KB to 100 KB) will prevent the transmission of the millions of characters required to trigger the CPU starvation loop.

Alternatively, developers can modify affected data models to bind incoming duration and calendar inputs as standard java.lang.String objects. After deserialization, the application code can manually validate that the string length does not exceed normal bounds (e.g., 100 characters) before passing the value to the DatatypeFactory constructor.