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

CVE-2026-91777 Overview

CVE-2026-91777 is an algorithmic complexity vulnerability in FasterXML jackson-databind affecting forward-reference completion for @JsonIdentityInfo object IDs. The flaw resides in CollectionDeserializer.CollectionReferringAccumulator.resolveForwardReference() and the equivalent path in MapDeserializer. When a JSON document creates unresolved object-ID references in an identity-enabled collection or map and then defines those IDs in reverse order, the deserializer performs a linear scan of the pending-reference accumulator for every resolved ID. This produces quadratic CPU work relative to input size, enabling denial of service through modestly sized JSON payloads.

Critical Impact
Attacker-influenced JSON deserialized into an identity-enabled collection or map triggers O(N²) CPU consumption, exhausting server resources without deep nesting or unusual syntax.

Affected Products

FasterXML jackson-databind (versions using the vulnerable CollectionReferringAccumulator and MapDeserializer forward-reference paths)
Java applications deserializing untrusted JSON into @JsonIdentityInfo-enabled collections or maps
Downstream libraries and frameworks bundling the affected jackson-databind versions

Discovery Timeline

2026-09-23 - CVE-2026-91777 published to the National Vulnerability Database (NVD)
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-91777

Vulnerability Analysis

The vulnerability is an algorithmic complexity flaw classified under [CWE-400] Uncontrolled Resource Consumption. Jackson's @JsonIdentityInfo feature allows objects to be referenced by an identifier before their definition appears in the JSON stream. Unresolved references accumulate in a pending-reference list until the target ID is parsed. When a target ID resolves, the deserializer walks the accumulator linearly and calls equals() on each entry's ID.

If a document produces N unresolved references and then resolves them in reverse order, each resolution scans a shrinking list, but the total identity comparisons grow as N * (N + 1) / 2. The reporter instrumented the ID class and measured exactly 2,003,000 equals() calls at N = 2,000, compared to zero comparisons in a control input where every reference was already resolved. The input requires no deep nesting and no malformed JSON, which makes payload construction trivial for an attacker.

Root Cause

The root cause is the use of a linear data structure for the pending-reference accumulator combined with per-resolution linear scans. Neither CollectionReferringAccumulator.resolveForwardReference() nor the MapDeserializer equivalent indexes pending references by ID. Every resolution therefore incurs O(N) work, and adversarial ordering forces the worst case on every resolved ID.

Attack Vector

Exploitation requires an application that deserializes attacker-influenced JSON into an identity-enabled collection or map. The attack vector is network-based and requires no authentication or user interaction. An attacker submits a shallow, syntactically ordinary JSON document containing N forward references followed by N target objects in reverse order. CPU utilization on the deserializing thread scales quadratically with N, degrading or halting service availability.

No verified proof-of-concept code is published. Refer to GitHub Issue #6204 and GHSA-cxp5-3px4-pw24 for the reporter's instrumentation details.

Detection Methods for CVE-2026-91777

Indicators of Compromise

Sustained single-thread CPU saturation on JVM processes handling JSON deserialization endpoints
Request latency growth that correlates with payload size rather than nesting depth
Thread dumps showing extended time in CollectionReferringAccumulator.resolveForwardReference() or MapDeserializer forward-reference paths
Repeated inbound JSON payloads containing many @id / @ref pairs with references preceding definitions

Detection Strategies

Enable JVM profiling or async-profiler sampling on deserialization services and alert on hot frames inside jackson-databind referring-accumulator code
Add application-layer request size and parsing-time budgets, logging any deserialization exceeding the budget
Inspect API gateway logs for JSON bodies with disproportionate identity-reference density relative to object count

Monitoring Recommendations

Instrument deserialization endpoints with per-request CPU time metrics and alert on quadratic growth patterns
Track jackson-databind version inventory across build manifests using software composition analysis
Correlate CPU spikes with request payloads to identify candidate exploitation attempts

How to Mitigate CVE-2026-91777

Immediate Actions Required

Upgrade jackson-databind to the fixed release identified in GHSA-cxp5-3px4-pw24
Audit application code for @JsonIdentityInfo usage on collections and maps that deserialize external input
Enforce strict maximum request body sizes on endpoints that accept JSON
Apply request timeouts and per-thread CPU budgets on deserialization workers

Patch Information

The upstream fix replaces the linear pending-reference lookup with a keyed pending-reference structure, reducing forward-reference resolution to expected O(1) per ID. Apply the fixed jackson-databind version referenced in the vendor advisory and rebuild dependent artifacts. Refer to GitHub Issue #6204 for the technical fix discussion.

Workarounds

Disable @JsonIdentityInfo on types that deserialize untrusted input where the feature is not required
Front deserialization endpoints with a reverse proxy that caps JSON body size and array element counts
Route deserialization onto bounded thread pools with aggressive timeouts to contain CPU exhaustion
Validate incoming JSON with a schema that rejects unbounded arrays of identity references

bash

# Configuration example
# Refer to vendor advisory GHSA-cxp5-3px4-pw24 for the fixed version identifier
# Example Maven dependency pin (replace VERSION with the patched release):
# <dependency>
#   <groupId>com.fasterxml.jackson.core</groupId>
#   <artifactId>jackson-databind</artifactId>
#   <version>VERSION</version>
# </dependency>