CVE-2026-91776: jackson-databind: unbounded growth of the type id cache in TypeDeserializerBase retains every unknown raw type ID
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
com.fasterxml.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 2.18.11 - Upgrade
Upgrade
com.fasterxml.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 2.21.7 - Upgrade
Upgrade
com.fasterxml.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 2.22.3 - Upgrade
Upgrade
tools.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 3.1.7 - Upgrade
Upgrade
tools.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 3.2.3
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Exposure requires name-based polymorphism configured with a fallback, such as Id.NAME with defaultImpl or an equivalent fallback. The application must also accept attacker-influenced type IDs and reuse a long-lived ObjectMapper across requests.
What does an attacker need to do to trigger the memory growth?
An attacker needs to submit many distinct unrecognized type IDs. Repeating the same unknown ID does not produce the same cache cardinality growth; each fresh unknown ID is retained as a separate cache key.
What can be done if the fix cannot be applied immediately?
Remove or avoid fallback behavior for name-based polymorphism where possible, and prevent untrusted inputs from controlling type IDs. Avoid reusing a long-lived ObjectMapper for processing such attacker-influenced data if the application architecture permits.
How can responders identify likely exploitation or impact?
Inspect the type deserializer cache for a large and growing number of distinct unknown type-ID keys mapping to fallback handling. The reported test retained 10,000 entries after 10,000 distinct unknown IDs, while repeating one unknown ID produced only one entry.