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.
Avoid binding javax.xml.datatype.Duration and javax.xml.datatype.XMLGregorianCalendar fields directly from untrusted JSON. Where such fields are required, impose a maximum request body size and a maximum string length at the transport layer, or bind the value as a String, length-check it, and convert it in application code.
Upgrade to jackson-databind 2.18.10, 2.21.6, 2.22.2 (com.fasterxml.jackson.core) or 3.1.6, 3.2.2 (tools.jackson.core). The fix applies the same validate-length-then-parse idiom already used by NumberDeserializers, calling StreamReadConstraints length validation on the raw string before delegating to DatatypeFactory. The guard deliberately does not extend to javax.xml.namespace.QName, whose local parts may legitimately be long.