[
https://issues.apache.org/jira/browse/KAFKA-21239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krishna Chidrawar updated KAFKA-21239:
--------------------------------------
Description:
*Aqua Description :* 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.
*Vendor Statement :* null
*Vendor URL :* null
*NVD URL :* [https://nvd.nist.gov/vuln/detail/CVE-2026-68497]
*Fix Version :* 2.18.10, 2.21.6, 2.22.2
*Aqua Description :* TypeDeserializerBase._findDeserializer() in FasterXML
jackson-databind caches the resolved deserializer under the raw,
attacker-supplied type ID. When name-based polymorphism is configured with a
fallback, for example @JsonTypeInfo(use = Id.NAME, defaultImpl = ...), every
distinct unrecognized type ID resolves to the same fallback deserializer but is
retained as its own key in the _deserializers map. That map has no configurable
bound and lives for the lifetime of the type deserializer, so an attacker who
can repeatedly supply fresh unknown type IDs causes monotonic memory retention
across requests. The reporter observed 10,000 retained entries from 10,000
distinct unknown IDs, against a single entry for a control that repeated one
unknown ID the same number of times, isolating attacker-controlled key
cardinality from request volume. Exploitation requires an application that
enables name-based polymorphism with a defaultImpl or equivalent fallback,
accepts attacker-influenced type IDs, and reuses a long-lived ObjectMapper
across requests. The fix stops caching fallback resolutions for unrecognized
IDs and bounds both the number of cached entries and the length of a cacheable
type ID.
*Vendor Statement :* null
*Vendor URL :* null
*NVD URL :* [https://nvd.nist.gov/vuln/detail/CVE-2026-91776]
*Fix Version :* 2.18.11, 2.21.7, 2.22.3
was:
*Aqua Description :* 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.
*Vendor Statement :* null
*Vendor URL :* null
*NVD URL :* [https://nvd.nist.gov/vuln/detail/CVE-2026-68497]
*Fix Version :* 2.18.10, 2.21.6, 2.22.2
> [CVE-2026-68497] [CVE-2026-91776] [jackson-databind]
> ----------------------------------------------------
>
> Key: KAFKA-21239
> URL: https://issues.apache.org/jira/browse/KAFKA-21239
> Project: Kafka
> Issue Type: Bug
> Reporter: Krishna Chidrawar
> Priority: Major
>
> *Aqua Description :* 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.
> *Vendor Statement :* null
> *Vendor URL :* null
> *NVD URL :* [https://nvd.nist.gov/vuln/detail/CVE-2026-68497]
> *Fix Version :* 2.18.10, 2.21.6, 2.22.2
>
> *Aqua Description :* TypeDeserializerBase._findDeserializer() in FasterXML
> jackson-databind caches the resolved deserializer under the raw,
> attacker-supplied type ID. When name-based polymorphism is configured with a
> fallback, for example @JsonTypeInfo(use = Id.NAME, defaultImpl = ...), every
> distinct unrecognized type ID resolves to the same fallback deserializer but
> is retained as its own key in the _deserializers map. That map has no
> configurable bound and lives for the lifetime of the type deserializer, so an
> attacker who can repeatedly supply fresh unknown type IDs causes monotonic
> memory retention across requests. The reporter observed 10,000 retained
> entries from 10,000 distinct unknown IDs, against a single entry for a
> control that repeated one unknown ID the same number of times, isolating
> attacker-controlled key cardinality from request volume. Exploitation
> requires an application that enables name-based polymorphism with a
> defaultImpl or equivalent fallback, accepts attacker-influenced type IDs, and
> reuses a long-lived ObjectMapper across requests. The fix stops caching
> fallback resolutions for unrecognized IDs and bounds both the number of
> cached entries and the length of a cacheable type ID.
> *Vendor Statement :* null
> *Vendor URL :* null
> *NVD URL :* [https://nvd.nist.gov/vuln/detail/CVE-2026-91776]
> *Fix Version :* 2.18.11, 2.21.7, 2.22.3
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
