CVE-2026-18401: Jackson-Core Async Parser DoS Vulnerability

CVE-2026-18401 Overview

CVE-2026-18401 is a denial-of-service vulnerability in the non-blocking (asynchronous) JSON parser of jackson-core. The async parser does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters), while the synchronous parser applies the limit correctly. An attacker who can submit JSON to an application using the async parser API can supply a number token of arbitrary length. This triggers excessive memory allocation and potential CPU exhaustion, resulting in denial of service. The flaw maps to CWE-770: Allocation of Resources Without Limits or Throttling.

Critical Impact
Unauthenticated attackers can send a single JSON document containing an arbitrarily long number to trigger OutOfMemoryError and O(n²) BigInteger parsing, causing service outages in reactive applications such as Spring WebFlux.

Affected Products

com.fasterxml.jackson.core:jackson-core versions 2.15.0 through 2.18.5
com.fasterxml.jackson.core:jackson-core versions 2.19.0 through 2.21.0
tools.jackson.core:jackson-core versions 3.0.0 through 3.0.x

Discovery Timeline

2026-08-04 - CVE-2026-18401 published to NVD
2026-08-04 - Last updated in NVD database

Technical Details for CVE-2026-18401

Vulnerability Analysis

The vulnerability affects the non-blocking parsing path implemented in NonBlockingUtf8JsonParserBase and related classes. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check. The parser then calls _valueComplete() to finalize the token. Unlike the synchronous path, _valueComplete() does not invoke resetInt() or resetFloat(), which are the methods in ParserBase that call validateIntegerLength() and validateFPLength(). Because the validation step is skipped entirely, maxNumberLength is never enforced on the async code path.

Root Cause

The root cause is inconsistent enforcement of StreamReadConstraints between parsing APIs. StreamReadConstraints was introduced in jackson-core 2.15.0 to bound resource usage during parsing. The synchronous parser routes number tokens through validation before completion, but the async parser accumulates unbounded input directly into the internal TextBuffer. Applications relying on default constraints therefore have no protection when they use the reactive parsing API.

Attack Vector

An attacker sends a crafted JSON document to any endpoint that parses input using the async API. The number token can be arbitrarily long, causing unbounded allocation in the TextBuffer. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM performs O(n²) BigInteger parsing, compounding memory pressure with CPU exhaustion. No authentication or user interaction is required beyond the ability to submit data for parsing. Reactive frameworks such as Spring WebFlux are common exposure points.

text

  (reported by @ventusfortis)
 #1548: `StreamReadConstraints.maxDocumentLength` not checked when
   creating parser with fixed buffer
+#1555: Enforce `StreamReadConstraints.maxNumberLength` for
+  non-blocking (async) parser
+ (fix by @pjfanning)

 2.18.5 (27-Oct-2025)
  (same as 2.18.4.1 on 10-June-2025)

Source: FasterXML/jackson-core commit b0c428e. This patch adds maxNumberLength enforcement to the non-blocking parser so it matches the synchronous parser's behavior.

Detection Methods for CVE-2026-18401

Indicators of Compromise

HTTP request bodies containing JSON number tokens exceeding 1000 characters submitted to endpoints backed by async parsers.
Application logs showing OutOfMemoryError originating from com.fasterxml.jackson.core.util.TextBuffer or NonBlockingUtf8JsonParserBase.
Sudden JVM heap growth or sustained high CPU correlated with calls to getBigIntegerValue() or getDecimalValue().

Detection Strategies

Inspect ingress traffic for JSON payloads with unusually long numeric literals and flag or reject requests exceeding a defined length threshold.
Instrument application metrics to track TextBuffer allocation size and alert on outliers on reactive endpoints.
Perform software composition analysis (SCA) to identify services depending on affected jackson-core versions.

Monitoring Recommendations

Monitor JVM heap utilization and garbage collection latency on services exposing async JSON endpoints.
Track HTTP 5xx spikes on Spring WebFlux or other reactive endpoints that deserialize JSON.
Aggregate stack traces containing NonBlockingUtf8JsonParserBase from centralized logs for retrospective hunting.

How to Mitigate CVE-2026-18401

Immediate Actions Required

Upgrade jackson-core to a patched release that includes the fix from pull request #1555.
Audit all services using the async parser API, particularly reactive applications built on Spring WebFlux.
Place a request-size limit at the ingress layer to reject oversized JSON documents before they reach the parser.

Patch Information

The fix is tracked in GHSA-72hv-8253-57qq and implemented in commit b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf. The patch enforces StreamReadConstraints.maxNumberLength on the non-blocking parser path, matching the synchronous parser's behavior. Upgrade to a released version of jackson-core that incorporates PR #1555 on both the 2.x and 3.x lines.

Workarounds

Enforce a strict maximum body size at the reverse proxy, API gateway, or WAF for endpoints that consume JSON.
Validate or reject JSON input containing numeric tokens longer than expected before invoking jackson-core.
Avoid invoking getBigIntegerValue() or getDecimalValue() on untrusted input to reduce CPU amplification risk.

bash

# Example NGINX ingress limit to cap JSON body size
http {
    client_max_body_size 64k;
}