CVE-2026-68497: jackson-databind Duration and XMLGregorianCalendar DoS

CVE-2026-68497 is a High-severity denial-of-service vulnerability (CWE-400) in jackson-databind, the data-binding layer of the Jackson JSON library for Java, scored 7.5 by HeroDevs (the CVE Numbering Authority, or CNA) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. FasterXML published the maintainer advisory (GHSA-q4xh-88c3-wmh7) on August 21, 2026, and HeroDevs published the CVE record on September 11, 2026. Jackson's default deserializers for javax.xml.datatype.Duration and XMLGregorianCalendar pass the raw JSON string to the JDK's DatatypeFactory, which parses digit runs of any length with quadratic-time BigInteger and BigDecimal constructors.

• Affected: com.fasterxml.jackson.core:jackson-databind 2.0.0 through 2.18.9, 2.19.0 through 2.21.5, and 2.22.0 through 2.22.1, plus tools.jackson.core:jackson-databind 3.0.0 through 3.1.5 and 3.2.0 through 3.2.1.
• Fixed upstream: 2.18.10, 2.21.6, 2.22.2, 3.1.6, and 3.2.2. Take the current patch on your line instead (2.18.12, 2.21.8, 2.22.4, 3.1.8, or 3.2.4), because the first fix releases are still exposed to three newer CVEs, one of them Critical.
• No OSS fix: the 2.13, 2.14, and 2.15 lines that Spring Boot 2.7 through 3.2 ship are end of life. NES for Jackson (HeroDevs Never-Ending Support) resolved CVE-2026-68497 in 2.13.11, 2.14.8, and 2.15.9; the current NES releases (2.13.13, 2.14.10, and 2.15.11) also close those three newer CVEs.

‍Affected and unsupported? See NES for Jackson.

What is CVE-2026-68497?

CVE-2026-68497 is an uncontrolled resource consumption bug (CWE-400; the CVE record also lists CWE-1333) in CoreXMLDeserializers, the jackson-databind component that binds JSON to the JDK's XML Schema datatypes.

Jackson registers these deserializers by default. Any POJO, record, or DTO with a javax.xml.datatype.Duration or javax.xml.datatype.XMLGregorianCalendar field gets them automatically. No module, no polymorphic typing, no special ObjectMapper configuration. A plain new ObjectMapper() or JsonMapper.builder().build() is exposed.

The XML Schema lexical grammar puts no upper bound on the length of numeric components. P99999Y is a valid duration of 99,999 years, and so is a P followed by five million nines and a Y. The JDK's DatatypeFactory.newDuration() turns each component into a BigInteger, and newXMLGregorianCalendar() turns fractional seconds into a BigDecimal. Both string constructors are O(n²) in digit count.

Jackson already defends against exactly this pattern for numbers. jackson-core's StreamReadConstraints.maxNumberLength (default 1,000) rejects oversized JSON number tokens, and jackson-databind's NumberDeserializers apply the same check to numbers that arrive as strings. The XML datatype path skipped that check. Because the attacker's digits sit inside a JSON string token, the only limit that applies is maxStringLength, which defaults to 20,000,000 characters on jackson-core 2.15.1 through 2.22 (5,000,000 on 2.15.0) and 100,000,000 on 3.x. Jackson 2.13 and 2.14 have no string limit at all.

CVE-2026-68497 severity and exploit conditions

NVD lists CVE-2026-68497 as Awaiting Analysis, so the HeroDevs (CNA) score above is the authoritative one for now. The GitHub advisory carries the same 7.5 vector.

Exploitation requires two things:

• The application deserializes attacker-controlled JSON into a type that has a Duration or XMLGregorianCalendar property, directly or nested inside another object or collection.
• The transport accepts a body large enough to carry the digits. Around 1 MB is enough to cost seconds of CPU; around 5 MB costs minutes.

The second condition is usually met by default. Spring MVC's @RequestBody JSON binding, JAX-RS providers, and most message consumers do not impose a small body limit unless you configure one.

CVE-2026-68497 exploitation status: is there a public PoC?

Yes. The maintainer advisory includes a complete proof of concept and measured timings against jackson-databind 3.2.1 on OpenJDK 25: a 1 MB payload took about 11 seconds of single-thread CPU to deserialize, and a 5 MB payload took about 293 seconds, against a 27 to 53 ms baseline for a normal P1Y value. CISA's ADP enrichment on the CVE record rates exploitation as "PoC" and the attack as automatable.

CVE-2026-68497 is not in the CISA Known Exploited Vulnerabilities catalog as of October 28, 2026. The payload shape is spelled out in the public CVE description, so assume anyone scanning for it already knows what to send. It is nothing more than an ordinary request body with an oversized value:

{
  "ttl": "P999999999999999999999 ... (about one million nines) ... 999Y"
}

The XMLGregorianCalendar form is the same idea with a timestamp whose fractional seconds run to millions of digits.

CVE-2026-68497 root cause in jackson-databind CoreXMLDeserializers

The vulnerable routine is CoreXMLDeserializers.Std._deserialize(String, DeserializationContext) (com.fasterxml.jackson.databind.ext on 2.x, tools.jackson.databind.ext on 3.x). On affected versions, the TYPE_DURATION branch returns _dataTypeFactory.newDuration(value) with the attacker's string untouched. The TYPE_G_CALENDAR branch first tries Jackson's own date parser, and when that throws, falls back to _dataTypeFactory.newXMLGregorianCalendar(value), again with no length check.

The cost is super-linear. The advisory's two data points show about 26 times the CPU for 5 times the payload, which is what you expect from an O(n²) parse. And the string ceiling sits far above the 5 MB the advisory tested: 20 million characters on current 2.x, 100 million on 3.x, and no ceiling at all on 2.13 and 2.14.

The upstream fix (FasterXML/jackson-databind#6127, first released in 2.18.10) adds a _validateTimestampLength() call on both branches before the DatatypeFactory is reached. It checks the whole value's length against StreamReadConstraints.getMaxNumberLength(), so any Duration or XMLGregorianCalendar string longer than 1,000 characters by default now fails with a StreamConstraintsException. No legitimate XML Schema duration or timestamp comes close to that length.

Is jackson-databind 2.13 affected by CVE-2026-68497?

Yes, jackson-databind 2.13 is affected. The GitHub advisory lists the earliest affected 2.x version as 2.14.0. The CVE record and the HeroDevs vulnerability directory entry list 2.0.0. We checked the published sources: jackson-databind 2.9.10 and 2.13.5 contain the same unguarded newDuration(value) and newXMLGregorianCalendar(value) calls, registered by default through findBeanDeserializer.

That gap matters in practice. Spring Boot 2.7 manages jackson-databind 2.13.5. Any tool that keys off the GitHub advisory's range can report a Spring Boot 2.7 application as unaffected when it is not.

There is a second reason the older lines are hard to fix yourself. The upstream patch relies on StreamReadConstraints, which jackson-core introduced in 2.15. On 2.13 and 2.14 there is no constraints object to read a limit from, so the upstream change cannot be applied as written.

What an attacker can do with CVE-2026-68497

• Send a JSON body to any endpoint whose request DTO has a Duration field, with that field set to a P, then millions of digits, then a Y, and hold one request thread plus one CPU core for tens of seconds to several minutes per request.
• Hit an XMLGregorianCalendar field the same way through the fractional-seconds path (a timestamp ending in a very long run of digits after the decimal point).
• Repeat the request from a handful of connections to occupy every core and stall the servlet container's worker pool (Spring Boot's embedded Tomcat defaults to 200 threads), denying service to every other client on that instance.
• Target services built on JAXB-generated models. The xjc compiler maps xs:duration to javax.xml.datatype.Duration and xs:dateTime to XMLGregorianCalendar by default, so SOAP-era schemas re-exposed as JSON APIs are the most likely to carry these fields.
• Publish one poisoned message to a Kafka topic, JMS queue, or other pipeline that deserializes JSON into such a type, stalling the consumer and building lag behind it on every redelivery.

CVE-2026-68497 does not disclose data or allow code execution. The impact is availability only.

Which jackson-databind versions are affected by CVE-2026-68497?

Branch status comes from the Jackson project's release page. Only 2.18, 2.21, 2.22, 3.1, and 3.2 are open, and 2.18 closes at the end of 2026 (see our Jackson versions and EOL dates reference). Patch 2.18 if you are on it, but 2.21 is the durable 2.x target.

One more thing before you pin the minimum fix versions. Three jackson-databind CVEs published after CVE-2026-68497 still affect the releases that fixed it:

• CVE-2026-110879, published October 28, 2026, is a Critical (9.8) PolymorphicTypeValidator bypass and an incomplete fix for CVE-2026-54512. It affects everything below 2.18.12, 2.21.8, 2.22.4, 3.1.8, and 3.2.4.
• CVE-2026-91777 and CVE-2026-91776 are two more High-severity denial-of-service flaws that list 2.18.10, 2.21.6, 2.22.2, 3.1.6, and 3.2.2 as still affected.

So taking the current patch on your line is not optional. Stopping at the first release that fixed CVE-2026-68497 leaves you on a Critical. That applies to managed versions too: check what your Spring Boot release actually resolves, because it is often not the latest Jackson patch.

jackson-databind almost always arrives transitively, so your pom.xml rarely tells the whole story. To see what you actually resolve:

# Maven
mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind,tools.jackson.core:jackson-databind

# Gradle
./gradlew dependencyInsight --dependency jackson-databind --configuration runtimeClasspath

Which Spring Boot versions ship a vulnerable jackson-databind?

Most teams get jackson-databind from Spring Boot's dependency management, so the Spring Boot line decides the Jackson line:

Spring Boot support dates are from endoflife.date; managed versions are from each release's spring-boot-dependencies POM on Maven Central and the NES for Spring Boot managed-version docs. Spring Boot 4.0.9 and 4.1.2 manage Jackson 3.1.7 and 2.21.7. Those fix CVE-2026-68497 but not CVE-2026-110879, which is why the Spring Boot 4 rows carry an override. We recommend 4.1.2 over 4.0.9 because the 4.0 line leaves OSS support in December 2026.

The override is two properties on Spring Boot 4 and one on Spring Boot 3:

<!-- Maven: Spring Boot 4.1.2 -->
<properties>
    <jackson-bom.version>3.1.8</jackson-bom.version>
    <jackson-2-bom.version>2.21.8</jackson-2-bom.version>
</properties>

// Gradle with the Spring dependency-management plugin: Spring Boot 4.1.2
ext['jackson-bom.version'] = '3.1.8'
ext['jackson-2-bom.version'] = '2.21.8'

On Spring Boot 3.3 through 3.5, set only jackson-bom.version (2.18.12 or 2.21.8 from the table above).

If you are on Spring Boot 2.7 through 3.5, the framework itself is also past OSS support, and Jackson is only one of the dependencies Spring Boot pins that stopped receiving fixes. NES for Spring covers the framework, and NES coverage for Spring Boot's managed dependencies delivers remediated versions at the original Maven coordinates.

How to fix CVE-2026-68497: mitigation guidance

If you cannot patch immediately:

• Limit request body size before JSON parsing. Most APIs never need multi-megabyte bodies. A limit of a few hundred KB at the reverse proxy, API gateway, or servlet filter shrinks the worst case from minutes to milliseconds, since the cost is quadratic in digit count.
• Lower maxStringLength on your JsonFactory (jackson-core 2.15 and later) if no legitimate field needs long strings. This bounds every string, so test it against your real payloads first.
• Add a length check on the affected fields. A custom deserializer registered for Duration takes precedence over Jackson's built-in one and closes the path on any version, including 2.13 and 2.14, which have no StreamReadConstraints to lean on. Use the same pattern for XMLGregorianCalendar.
• Find your exposure. Search your models for javax.xml.datatype.Duration and XMLGregorianCalendar, including JAXB-generated classes. If none are bound from untrusted input, the vulnerable code is unreachable in your application, though your scanner will still flag the version.

A minimal length guard for Duration, which we compiled and tested against jackson-databind 2.13.5 (a one-million-digit value is rejected in milliseconds):

import com.fasterxml.jackson.core.JsonParser;
import com.fasterxml.jackson.databind.DeserializationContext;
import com.fasterxml.jackson.databind.deser.std.StdScalarDeserializer;
import java.io.IOException;
import javax.xml.datatype.DatatypeConfigurationException;
import javax.xml.datatype.DatatypeFactory;
import javax.xml.datatype.Duration;

public class BoundedDurationDeserializer extends StdScalarDeserializer<Duration> {
    private static final int MAX_LENGTH = 64; // no real xs:duration comes close
    private final DatatypeFactory factory;

    public BoundedDurationDeserializer() throws DatatypeConfigurationException {
        super(Duration.class);
        this.factory = DatatypeFactory.newInstance();
    }

    @Override
    public Duration deserialize(JsonParser p, DeserializationContext ctxt) throws IOException {
        String text = p.getValueAsString();
        if (text == null) {
            return (Duration) ctxt.handleUnexpectedToken(Duration.class, p);
        }
        text = text.trim();
        if (text.length() > MAX_LENGTH) {
            return (Duration) ctxt.handleWeirdStringValue(Duration.class, text,
                    "Duration longer than %d characters", MAX_LENGTH);
        }
        try {
            return factory.newDuration(text);
        } catch (IllegalArgumentException e) {
            return (Duration) ctxt.handleWeirdStringValue(Duration.class, text, e.getMessage());
        }
    }
}

Register it with new SimpleModule().addDeserializer(Duration.class, new BoundedDurationDeserializer()). In Spring Boot, expose that module as a @Bean and the auto-configured ObjectMapper picks it up.

Related jackson-databind CVEs

CVE-2026-68497 is the databind half of a pattern Jackson has been closing all year (2026): a length limit that exists on one parsing path but not another.

• CVE-2026-18401: jackson-core's non-blocking (async) parser did not enforce maxNumberLength, the same guard CVE-2026-68497 sidesteps
• CVE-2026-68494: incomplete fix for CVE-2026-18401, where digits accumulated across input chunks still bypassed the limit
• CVE-2026-110879: Critical PolymorphicTypeValidator bypass through generic type arguments, an incomplete fix for CVE-2026-54512, still present in the releases that fixed CVE-2026-68497
• CVE-2026-91777: quadratic forward-reference completion in collection and map deserialization, also still present in those releases
• CVE-2026-91776: unbounded growth of the type id cache in TypeDeserializerBase, also still present in those releases
• CVE-2026-83557 and CVE-2026-19032: a PolymorphicTypeValidator gap and a java.nio.file.Path scheme-resolution flaw, fixed in the same 2.18.10, 2.21.6, 2.22.2, 3.1.6, and 3.2.2 releases
• CVE-2025-52999: jackson-core stack overflow on deeply nested input, covered in our CVE-2025-52999 write-up

More of this year's Jackson coverage: CVE-2026-54512 and CVE-2026-54513 (the PolymorphicTypeValidator bypasses that CVE-2026-110879 reopens), CVE-2026-59888 (a @JsonIgnore bypass on records), and CVE-2026-41855 (a Jackson deserialization flaw in Spring Framework's JMS support).

Taking action on CVE-2026-68497

If you control your Jackson version and are on an open branch, upgrade to the current patch release on your line, not the minimum fix version. With CVE-2026-110879 published on October 28, 2026, the minimum fix version leaves you on a Critical. On Spring Boot 4, that means Spring Boot 4.1.2 plus a jackson-bom.version override to 3.1.8 (and jackson-2-bom.version to 2.21.8).

The harder case is the large installed base on Spring Boot 2.7 through 3.2, which runs jackson-databind 2.13, 2.14, or 2.15. Those Jackson lines closed years ago, the upstream fix depends on an API that 2.13 and 2.14 do not have, and a scanner reading the GitHub advisory may not flag 2.13 at all. Jumping to jackson-databind 2.18 or 2.21 under a framework that was never tested against it trades a known CVE for unknown regressions.

NES for Jackson ships drop-in replacements for jackson-databind 2.13, 2.14, and 2.15. CVE-2026-68497 was resolved in 2.13.11, 2.14.8, and 2.15.9, and the current releases (2.13.13, 2.14.10, and 2.15.11, released October 23, 2026) also close CVE-2026-91776, CVE-2026-91777, and CVE-2026-110879, so you can stay on the Jackson and Spring Boot versions your application was built and tested on. HeroDevs is the founding member of the Commonhaus Foundation's Open Source Sustainability Initiative, and Commonhaus is the foundation that governs Jackson.