CVE-2026-91776 in jackson-databind
Summary
by MITRE • 09/23/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability resides within the TypeDeserializerBase._findDeserializer() method in the FasterXML jackson-databind library, representing a significant resource management flaw that leads to unbounded memory consumption. This issue specifically affects applications configured with name-based polymorphism using a fallback mechanism, such as @JsonTypeInfo(use = Id.NAME, defaultImpl = ...). In this configuration, when an unrecognized type ID is encountered, the system resolves it to a designated fallback deserializer rather than throwing an immediate error. However, the internal caching logic retains every distinct unrecognized type ID as a unique key within the _deserializers map. This map lacks any configurable size limit and persists for the entire lifetime of the TypeDeserializer instance, which typically corresponds to the lifespan of the ObjectMapper bean in most enterprise applications. Consequently, this design creates a direct pathway for memory exhaustion attacks driven by attacker-controlled input cardinality rather than request volume alone.
From an operational perspective, this flaw enables a denial-of-service scenario where an adversary can systematically exhaust server resources through simple HTTP requests containing malicious JSON payloads. By repeatedly submitting fresh and distinct unknown type IDs in the polymorphic field of incoming data structures, an attacker forces the application to allocate new entries for each unique ID without ever evicting them from memory. Empirical observations confirm that sending ten thousand distinct unrecognized identifiers results in exactly ten thousand retained cache entries, whereas repeating a single identifier only retains one entry despite identical request volume. This isolation proves that the attack vector relies on key cardinality rather than throughput, allowing attackers to target systems with relatively low bandwidth requirements while still achieving catastrophic memory growth over time. The impact is particularly severe for long-running services that reuse ObjectMapper instances across thousands of requests, as the garbage collector cannot reclaim these cached entries until the application context is destroyed or restarted.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, and falls under the broader category of inefficient memory management patterns often exploited in Java-based web applications. In terms of offensive security frameworks, this technique corresponds to ATT&CK tactic T1496, Resource Hijacking, specifically through environmental exploitation where an attacker consumes system resources to degrade service availability. The exploitability is contingent upon specific application configurations: the target must enable name-based polymorphism with a default implementation or fallback handler, accept user-supplied type identifiers in JSON payloads, and utilize long-lived ObjectMapper instances that cache deserializer metadata across multiple requests. Without these conditions met simultaneously, the vulnerability remains theoretical; however, given the widespread adoption of Jackson for data binding in Spring Boot and other Java ecosystems, many applications are potentially exposed if they do not explicitly disable polymorphic typing or restrict allowed type IDs to a strict whitelist.
Mitigation strategies must address both the immediate code-level flaw and broader architectural defenses. The primary remediation involves upgrading jackson-databind to versions that implement bounds on cache size and limit the length of cacheable type identifiers, effectively preventing unbounded growth of the _deserializers map. For applications unable to upgrade immediately, developers should avoid using name-based polymorphism with fallbacks for fields derived from user input. Instead, they can restrict deserialization by configuring a whitelist of allowed types or disabling default typing entirely if not strictly required. Additionally, implementing rate limiting on endpoints that accept complex JSON structures and monitoring JVM heap usage metrics can help detect early signs of this abuse pattern before it leads to full service outage. Regular security audits focusing on Jackson configuration settings are essential to ensure that polymorphic features are either disabled for untrusted inputs or properly constrained with explicit type filters.