
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: >= 2.19.0, <= 2.21.6
Patched in 2.21.7
Vulnerable: >= 3.0.0, <= 3.1.6
Patched in 3.1.7
Vulnerable: >= 3.2.0, <= 3.2.2
Patched in 3.2.3
Vulnerable: >= 2.5.0, <= 2.18.10
Patched in 2.18.11
Vulnerable: >= 2.22.0, <= 2.22.2
Patched in 2.22.3
Details
When an @JsonIdentityInfo collection or map first creates N unresolved
object-ID references and later resolves the same IDs in reverse order,
jackson-databind scans the remaining pending-reference accumulator for each
resolution. A shallow JSON document whose size grows linearly can therefore
cause quadratic CPU work during deserialization.
The affected path is forward-reference completion in
CollectionDeserializer.CollectionReferringAccumulator.resolveForwardReference()
and the corresponding map implementation. The implementation performs a
linear search of the pending accumulator for every resolved object ID.
The behavior is runtime-confirmed in jackson-databind 2.5.0, 2.22.1, and 3.2.1. Current 2.22 and 3.2 source branches retained the same design when rechecked. A 2.4.0 control fails closed before successful reverse-order completion, so 2.5.0 is the conservative runtime-confirmed affected floor. The patched versions are: 2.18.11, 2.21.7, 2.22.3, 3.1.7 and 3.2.3.
The vulnerable application must deserialize attacker-influenced JSON into an identity-enabled collection or map. The issue does not require deep nesting or syntactically unusual JSON.
Suggested correction: replace repeated linear lookup/removal with a keyed pending-reference structure or another design that provides linear or amortized-linear completion. A regression should preserve input order, duplicate-ID behavior, and unresolved-ID errors while bounding reverse-order resolution work.
The proof constructs a shallow collection containing N unresolved
@JsonIdentityInfo references followed by definitions of those same IDs in
reverse order. Its ID class counts equals() calls, giving a deterministic
work measure rather than a timing-dependent result.
With N=2,000, affected versions perform exactly 2,003,000 ID comparisons. An
equally sized control in which every reference is already resolved performs
zero comparisons in the pending-reference lookup path. The run is bounded to
a 512 MiB JVM. The result demonstrates quadratic growth: approximately
N * (N + 1) / 2 comparisons, plus fixed setup comparisons.
An unauthenticated source that can submit JSON to an application using the affected identity-enabled collection or map shape can consume quadratic CPU and exhaust a request-time or worker-capacity budget, causing denial of service. The application model/configuration prerequisite is material. No confidentiality, integrity, code-execution, or parser-depth impact is claimed.
Requested credit: Daniel Birtwhistle
EPSS, exploit probability
Low0.56%
estimated chance of real-world exploitation in the next 30 days, higher than 47.4% of every CVE FIRST.org scores
Refreshed 11/15/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
More maven advisories
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.