CVE-2022-42004: The jackson-databind DoS Explained

CVE-2022-42004 is a denial-of-service vulnerability in FasterXML jackson-databind, caused by a missing depth check in BeanDeserializer._deserializeFromArray that lets deeply nested arrays exhaust available resources during deserialization. It affects jackson-databind before 2.12.7.1 and the 2.13.x line before 2.13.4, and it carries a CVSS 3.x base score of 7.5 (High) on the NVD. The important nuance, and the one that determines whether you are actually exposed, is that the vulnerable code path only triggers when the UNWRAP_SINGLE_VALUE_ARRAYS deserialization feature is explicitly enabled. If you have never turned that feature on, your risk from this specific CVE is materially lower.

What jackson-databind is and why this matters

jackson-databind is the data-binding layer of the Jackson library, the most widely used JSON toolkit in the Java ecosystem. It converts JSON into Java objects and back, and it sits inside Spring, countless REST frameworks, and an enormous share of enterprise Java services, usually as a transitive dependency you never added by hand. That reach is why a jackson-databind CVE ripples through so many security bulletins at once; vendors from IBM to AWS published advisories referencing this one.

Because it is so often transitive, the first challenge is simply knowing whether you ship it and at what version.

The technical root cause

When Jackson deserializes JSON, BeanDeserializer handles binding a JSON structure to a Java bean. The _deserializeFromArray method processes the case where a JSON array is being mapped, and in the affected versions it lacked a guard against arrays nested to an extreme depth.

Deserialization of deeply nested structures is inherently recursive, and each level of nesting consumes stack and processing resources. Without a depth cap, an attacker who can send a crafted JSON payload of many thousands of nested arrays forces the parser to recurse until it exhausts resources, degrading or crashing the service. That is the denial-of-service condition; there is no code execution here, unlike some of the older jackson deserialization gadget CVEs.

The gating condition is UNWRAP_SINGLE_VALUE_ARRAYS. This is an opt-in deserialization feature that tells Jackson to accept a single-element array where a scalar is expected. _deserializeFromArray is reached through that path, so an application that never enables the feature does not exercise the vulnerable code. That does not mean you should skip patching (defense in depth, and the feature can be enabled by a framework you do not control), but it explains why exploitability varies across otherwise identical version stacks.

CVE-2022-42004 was disclosed alongside CVE-2022-42003, a closely related jackson-databind resource-exhaustion issue in the same release window. Teams usually remediate both together because the fix versions overlap.

Affected and fixed versions

Here is the version picture, verified against the NVD and the GitHub advisory:

Affected:  jackson-databind < 2.12.7.1
           jackson-databind 2.13.0 - 2.13.3
Fixed in:  jackson-databind 2.12.7.1   (2.12.x branch)
           jackson-databind 2.13.4     (2.13.x branch)

The 2.14.x line and later are not affected. If you are on 2.13.x, upgrade to 2.13.4 or higher; if you are pinned to 2.12.x for compatibility, 2.12.7.1 carries the backported fix.

Finding it in your build

You cannot patch what you cannot see, and jackson-databind is usually transitive. Maven's dependency tree tells you the resolved version and what pulls it in:

mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind

For Gradle:

./gradlew dependencyInsight --dependency jackson-databind

The output shows which of your direct dependencies drags in the vulnerable version, which tells you whether you can bump it directly or need to override it. Because this is exactly the transitive-dependency case, a continuous SCA scan is more reliable than a one-time manual check; it flags the vulnerable version wherever it resolves in the tree and alerts you if a future build reintroduces it. We cover Jackson's broader vulnerability history in our Jackson databind security guide.

Remediation

The clean fix is to upgrade jackson-databind to a patched version. When the vulnerable version arrives transitively, force the resolved version rather than editing the offending dependency.

Maven, using the BOM to keep the whole Jackson family aligned:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson</groupId>
      <artifactId>jackson-bom</artifactId>
      <version>2.13.4</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Gradle, forcing the resolution:

configurations.all {
    resolutionStrategy {
        force 'com.fasterxml.jackson.core:jackson-databind:2.13.4'
    }
}

If you genuinely cannot upgrade immediately, the interim mitigation is to ensure UNWRAP_SINGLE_VALUE_ARRAYS is disabled (it is off by default) and to cap request body size at the edge so an attacker cannot send an arbitrarily large nested payload. Those reduce exposure but are not a substitute for the version bump.

After remediating, re-scan to confirm the vulnerable version is gone from every module, and record a VEX statement if any component legitimately cannot be updated so downstream consumers know your assessment.

FAQ

How severe is CVE-2022-42004?

It carries a CVSS 3.x base score of 7.5 (High) on the NVD. The impact is denial of service through resource exhaustion, not remote code execution. Severity in your environment depends on whether the vulnerable deserialization path is reachable, which is gated by the UNWRAP_SINGLE_VALUE_ARRAYS feature.

What versions of jackson-databind fix CVE-2022-42004?

Upgrade to 2.13.4 on the 2.13.x branch, or 2.12.7.1 on the 2.12.x branch. The 2.14.x line and later are not affected.

Is my application exploitable if I never enabled UNWRAP_SINGLE_VALUE_ARRAYS?

The vulnerable code path in _deserializeFromArray is reached through that feature, which is off by default, so an application that never enables it has significantly lower exposure. Still patch, because a framework in your stack could enable it and defense in depth is cheap.

How is CVE-2022-42004 related to CVE-2022-42003?

Both are jackson-databind resource-exhaustion (DoS) issues disclosed in the same window with overlapping fix versions. Teams typically remediate them together by upgrading to 2.13.4 or 2.12.7.1.