CVE-2026-68494: Jackson Core DoS Vulnerability

CVE-2026-68494 Overview

CVE-2026-68494 is an incomplete fix vulnerability in the jackson-core library's non-blocking JSON parser. The earlier patch for CVE-2026-18401 wired the validateIntegerLength() check into most number-parsing paths but omitted the streaming integer-digit path. An attacker who feeds JSON to the async parser in many small chunks, without ever sending a terminator byte, keeps the parser inside the MINOR_NUMBER_INTEGER_DIGITS state indefinitely. The internal accumulator grows on every chunk and is bounded only by maxStringLength (20 MiB default) instead of maxNumberLength (1000 default), an amplification of roughly 20,000x. Reactive frameworks including Spring WebFlux, Reactor, Quarkus, Helidon, and Vert.x are directly exposed because they feed inbound bytes to the async parser as they arrive [CWE-770].

Critical Impact

A single connection can drive approximately 40 MiB of JVM heap consumption per malformed number, and attacker-controlled concurrency can exhaust the heap and deny service.

Affected Products

• com.fasterxml.jackson.core:jackson-core versions 2.15.0 through 2.18.7
• com.fasterxml.jackson.core:jackson-core versions 2.19.0 through 2.21.3
• tools.jackson.core:jackson-core versions 3.0.0 through 3.1.3

Discovery Timeline

• 2026-05-21 - Fix commit lands in jackson-core
• 2026-08-04 - CVE-2026-68494 published to NVD
• 2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-68494

Vulnerability Analysis

The vulnerability is an allocation of resources without limits flaw in the NonBlockingUtf8JsonParserBase class. The prior fix for CVE-2026-18401 introduced a _setIntLength() helper that invokes validateIntegerLength() when a terminator byte, ., e, or E is encountered, or when input ends inside a fully buffered number. The helper was not invoked on the path where the parser exhausts its current input buffer while still consuming integer digits and returns NOT_AVAILABLE to the caller.

On that path, _textBuffer.expandCurrentSegment() extends the digit accumulator on every incoming chunk without ever consulting maxNumberLength. Because Java char values occupy two bytes, the ceiling is roughly 40 MiB of heap per parser instance. The equivalent fraction path in _finishFloatFraction() correctly calls _setFractLength() before returning NOT_AVAILABLE and is not affected.

Root Cause

The missing call sites are the integer-digit paths in _startPositiveNumber(), _startNegativeNumber(), and _finishNumberIntegralPart() in NonBlockingUtf8JsonParserBase. Operators who set StreamReadConstraints.maxNumberLength expecting it to cap per-value memory do not receive that guarantee for the streaming integer path.

Attack Vector

Exploitation requires only network access to a parsing endpoint that uses the non-blocking parser. No privileges or user interaction are needed. The attacker opens a connection, sends a partial JSON number consisting of digits, and withholds the terminator while streaming additional digits in small chunks. The synchronous parsers UTF8StreamJsonParser and ReaderBasedJsonParser, and the async parser operating on complete input, are not affected.

// Patch fragment from NonBlockingUtf8JsonParserBase.java
// Source: https://github.com/FasterXML/jackson-core/commit/4cdd529749da396cc7edf6d4a2aad41d47902641
            if (++_inputPtr >= _inputEnd) {
                _minorState = MINOR_NUMBER_INTEGER_DIGITS;
                _textBuffer.setCurrentLength(outPtr);
+                _setIntLength(outPtr);
                return _updateTokenToNA();
            }
            ch = getByteFromBuffer(_inputPtr) & 0xFF;

The added _setIntLength(outPtr) call ensures validateIntegerLength() runs before the parser returns control to the caller on the streaming path.

Detection Methods for CVE-2026-68494

Indicators of Compromise

• Sustained heap growth on JVM instances hosting reactive endpoints, correlated with individual long-lived HTTP or gRPC connections.
• Inbound HTTP request bodies containing extremely long runs of digit characters without a terminator, delivered across many TCP segments.
• OutOfMemoryError events in application logs originating from com.fasterxml.jackson.core.util.TextBuffer.expandCurrentSegment.

Detection Strategies

• Inventory application dependencies for jackson-core versions in the affected ranges using software composition analysis tooling.
• Instrument reactive endpoints to alert when a single request body exceeds a reasonable size threshold before parsing completes.
• Enable JVM heap and garbage collection telemetry to detect anomalous per-connection allocation patterns tied to JSON parsing threads.

Monitoring Recommendations

• Track heap occupancy and old-generation growth on services using Spring WebFlux, Quarkus, Helidon, or Vert.x.
• Alert on repeated MINOR_NUMBER_INTEGER_DIGITS stalls if you have instrumented the async parser, or on abnormal accumulator sizes in TextBuffer.
• Monitor for connections that send small frequent chunks yet never reach a JSON token boundary.

How to Mitigate CVE-2026-68494

Immediate Actions Required

• Upgrade jackson-core to a fixed release: 2.18.8 or later on the 2.18.x line, 2.21.4 or later on the 2.21.x line, or 3.1.4 or later on the 3.x line. The 2.22.x and 3.2.x lines contain the fix from their initial releases.
• Apply request body size limits at the HTTP layer or reverse proxy so a single request cannot buffer beyond an operationally reasonable size.
• Cap concurrent connections per client on internet-facing reactive endpoints to reduce the aggregate heap an attacker can force.

Patch Information

The fix adds _setIntLength() calls on the streaming integer paths in NonBlockingUtf8JsonParserBase. Refer to the GitHub Security Advisory GHSA-r7wm-3cxj-wff9 and the merged pull request #1611 for the authoritative patch content.

Workarounds

• Terminate or reject requests that stall inside the parser beyond a bounded time budget at the framework layer.
• Enforce request body size limits at the ingress or API gateway, ideally well below the 20 MiB maxStringLength default.
• Where feasible, route JSON parsing through the synchronous UTF8StreamJsonParser or ReaderBasedJsonParser on complete input rather than the non-blocking parser.

# Example: cap request body size in an NGINX ingress in front of a reactive service
client_max_body_size 1m;
client_body_timeout 5s;
client_body_buffer_size 16k;