CVE-2026-91776: FasterXML jackson-databind DOS Vulnerability

CVE-2026-91776 Overview

CVE-2026-91776 is a memory exhaustion vulnerability in FasterXML jackson-databind. The flaw resides in TypeDeserializerBase._findDeserializer(), which caches resolved deserializers under raw, attacker-supplied type identifiers. When an application configures name-based polymorphism with a fallback such as @JsonTypeInfo(use = Id.NAME, defaultImpl = ...), each unrecognized type ID resolves to the same fallback deserializer yet occupies a distinct entry in the _deserializers map. The map is unbounded and lives for the lifetime of the type deserializer. Attackers who submit fresh unknown type IDs cause monotonic memory growth across requests, leading to denial of service on long-lived ObjectMapper instances.

Critical Impact
Repeated requests carrying distinct unknown polymorphic type IDs cause unbounded growth of the internal deserializer cache, exhausting JVM heap and forcing service outage.

Affected Products

FasterXML jackson-databind (versions where TypeDeserializerBase._findDeserializer() caches fallback resolutions without bounds)
Java applications using @JsonTypeInfo(use = Id.NAME, defaultImpl = ...) with attacker-influenced type IDs
Services that share a long-lived ObjectMapper across HTTP requests

Discovery Timeline

2026-09-23 - CVE-2026-91776 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-91776

Vulnerability Analysis

The vulnerability is a resource exhaustion flaw classified under [CWE-400]. jackson-databind supports polymorphic deserialization by mapping a type identifier in the JSON payload to a Java class. When configured with Id.NAME and a defaultImpl, the library falls back to a default deserializer for unrecognized identifiers. The library then caches that resolution keyed by the raw input string.

The reporter demonstrated the amplification with a controlled experiment. Sending 10,000 distinct unknown type IDs produced 10,000 retained cache entries. Sending the same unknown ID 10,000 times produced a single entry. This isolates attacker-controlled key cardinality from request volume as the driver of memory retention.

Because the _deserializers map has no upper bound and shares the lifetime of the enclosing type deserializer, retained entries accumulate for the life of the process. Applications reusing a single ObjectMapper, which is the standard performance pattern, cannot recover the memory without restart.

Root Cause

The root cause is the caching logic inside TypeDeserializerBase._findDeserializer(). The function stores fallback resolutions under the raw type ID supplied by the caller instead of a canonical key derived from the resolved class. There is no size cap on the map and no length cap on cacheable keys. Any request path that reaches polymorphic deserialization with a defaultImpl fallback contributes to unbounded growth.

Attack Vector

An unauthenticated remote attacker sends JSON payloads containing a polymorphic type property with a random, unrecognized identifier. Each unique identifier adds one entry to the cache. High-cardinality submission drives memory pressure until garbage collection thrashes or the JVM throws OutOfMemoryError. Exploitation requires three conditions: name-based polymorphism with a defaultImpl or equivalent fallback, attacker influence over type IDs in the payload, and a long-lived ObjectMapper shared across requests.

Refer to the GitHub Security Advisory GHSA-wv8q-qhhj-9h54 and GitHub Issue #6203 for the reporter's proof-of-concept methodology.

Detection Methods for CVE-2026-91776

Indicators of Compromise

Sustained heap growth in JVM processes running services that expose polymorphic deserialization endpoints
High rate of inbound requests containing unique or randomized values in polymorphic type discriminator fields such as @type
Repeated OutOfMemoryError events without a corresponding increase in legitimate traffic volume
Heap dumps showing large _deserializers maps inside TypeDeserializerBase instances

Detection Strategies

Instrument application heap metrics and alert on monotonic growth trends across jackson-databind internal caches
Log and audit inbound JSON payloads for unusual cardinality of polymorphic type identifiers per source IP or session
Perform static review of Java codebases for @JsonTypeInfo(use = Id.NAME, defaultImpl = ...) annotations combined with untrusted input paths

Monitoring Recommendations

Deploy Java Flight Recorder or equivalent JVM profiling to capture allocation hotspots inside TypeDeserializerBase
Track dependency inventories for vulnerable jackson-databind versions across build systems and container images
Correlate application heap alerts with WAF logs showing anomalous request patterns targeting deserialization endpoints

How to Mitigate CVE-2026-91776

Immediate Actions Required

Upgrade jackson-databind to a fixed release that stops caching fallback resolutions for unrecognized IDs and bounds cache size and key length
Inventory all applications using @JsonTypeInfo with defaultImpl and validate whether type IDs derive from untrusted input
Restart long-running JVM services after upgrade to clear any previously retained cache entries

Patch Information

The upstream fix stops caching fallback resolutions for unrecognized type IDs and adds bounds to both the number of cached entries and the maximum length of a cacheable type ID. Refer to the GitHub Security Advisory GHSA-wv8q-qhhj-9h54 for fixed version details and the upstream tracking issue #6203 for commit references.

Workarounds

Remove defaultImpl from @JsonTypeInfo annotations where feasible so unknown type IDs raise an exception instead of resolving to a cached fallback
Validate polymorphic type identifiers against an allow-list before invoking ObjectMapper.readValue()
Deploy WAF rules that reject payloads with abnormally long or high-cardinality type discriminator values
Periodically recycle ObjectMapper instances or JVM processes in environments where upgrade is not immediately possible

bash

# Configuration example: pin a fixed jackson-databind version in Maven
# Replace <fixed-version> with the patched release from the GHSA advisory
mvn versions:set-property -Dproperty=jackson.version -DnewVersion=<fixed-version>
mvn dependency:tree | grep jackson-databind