CVE-2026-68494 in jackson-core
Summary
by MITRE • 08/04/2026
The fix released in jackson-core 2.18.6 and 2.21.1 for CVE-2026-18401 (GHSA-72hv-8253-57qq, number length constraint bypass in the non-blocking parser) is incomplete. This record covers the remaining bypass.
The earlier fix wired validateIntegerLength() into a new _setIntLength() helper and invoked it wherever the integer portion of a number is decided: a terminator byte arrives, a . or e/E is seen, or input ends inside a fully buffered value. It was not invoked on the attacker-relevant path where the parser runs out of input while still inside the MINOR_NUMBER_INTEGER_DIGITS minor state and returns NOT_AVAILABLE to the caller.
As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, keeps the parser inside MINOR_NUMBER_INTEGER_DIGITS indefinitely. _textBuffer.expandCurrentSegment() grows the accumulator on every chunk while validateIntegerLength() is never called. The accumulator is bounded only by maxStringLength (20 MiB by default) rather than by maxNumberLength (1000 by default), an amplification of roughly 20,000x over the documented limit. Because Java char values occupy two bytes, a single connection can be driven to approximately 40 MiB of heap before the validator finally fires when the value completes.
The equivalent fraction-path code is correct: _finishFloatFraction() calls _setFractLength() before its NOT_AVAILABLE return. The missing call affects the integer-digit paths in _startPositiveNumber(), _startNegativeNumber() and _finishNumberIntegralPart() in NonBlockingUtf8JsonParserBase.
Impact: reactive frameworks such as Spring WebFlux/Reactor, Quarkus, Helidon and Vert.x feed inbound HTTP or gRPC bytes to the async parser as they arrive, which is precisely the chunked-feed shape required. Operators who set StreamReadConstraints.maxNumberLength expecting it to cap memory per number value do not get that guarantee; memory accumulates per concurrent connection and attacker-controlled concurrency can exhaust the JVM heap. The synchronous parsers (UTF8StreamJsonParser, ReaderBasedJsonParser) and the async parser operating on complete input are not affected.
Exploitation requires only the ability to stream data to a parsing endpoint; no privileges or user interaction are needed.
This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.7, from 2.19.0 through 2.21.3, and from 2.22.0 through 2.22.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.1.3 and from 3.2.0 through 3.2.0. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-r7wm-3cxj-wff9 states the affected 2.x range without a lower bound.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/04/2026
The vulnerability described in CVE-2026-18401 represents a critical security flaw within the Jackson JSON parsing library, specifically affecting the non-blocking parser implementation. This issue stems from an incomplete fix for a previously identified problem that allowed bypassing number length constraints during parsing operations. The root cause lies in the improper handling of integer digit validation when processing large numeric values through asynchronous input streams, particularly in scenarios where data arrives in small chunks without clear terminators.
The flaw manifests in the NonBlockingUtf8JsonParserBase class, where the validateIntegerLength() function was correctly wired into a helper method _setIntLength() but fails to execute during certain parser states. Specifically, when the parser encounters an input stream that runs out of data while still inside the MINOR_NUMBER_INTEGER_DIGITS state, it returns NOT_AVAILABLE to the caller without invoking the length validation routine. This creates a path where attacker-controlled data can accumulate indefinitely within the _textBuffer accumulator, bypassing the intended maxNumberLength limit of 1000 digits and instead being constrained only by maxStringLength which defaults to 20 MiB.
This vulnerability operates under the Common Weakness Enumeration (CWE) category CWE-770, which deals with allocation of resources without limits or with inadequate limits. The issue directly impacts memory consumption patterns and can lead to resource exhaustion attacks. The operational impact extends across reactive frameworks such as Spring WebFlux/Reactor, Quarkus, Helidon, and Vert.x, where asynchronous parsing is standard practice. These platforms feed inbound HTTP or gRPC bytes incrementally to the async parser, creating the exact conditions necessary for exploitation.
The memory amplification factor of approximately 20,000x occurs because each chunk of data causes the text buffer to expand while validateIntegerLength() remains uninvoked, allowing accumulation up to 40 MiB of heap memory per connection before validation finally triggers upon value completion. This represents a severe security risk as attackers can consume substantial heap resources through concurrent connections without requiring any privileges or user interaction. The asynchronous parsers that operate on complete input datasets and synchronous parsers remain unaffected by this vulnerability.
The fix for this issue requires ensuring that _setIntLength() is properly called in all code paths where integer digits are processed, including the specific paths in _startPositiveNumber(), _startNegativeNumber(), and _finishNumberIntegralPart(). The correct implementation pattern already exists in the fraction path code through _finishFloatFraction() which correctly calls _setFractLength() before returning NOT_AVAILABLE. This oversight demonstrates a failure in defensive programming practices and highlights the importance of consistent validation across all parser states.
The affected versions span multiple release lines including jackson-core 2.15.0 through 2.18.7, 2.19.0 through 2.21.3, 2.22.0 through 2.22.0, and tools.jackson.core 3.0.0 through 3.1.3, 3.2.0 through 3.2.0. Notably, versions prior to 2.15.0 are not affected because StreamReadConstraints and the maxNumberLength setting were introduced in version 2.15.0, making earlier releases immune to this particular bypass mechanism.
This vulnerability aligns with ATT&CK technique T1499.004, which involves resource exhaustion attacks through memory consumption manipulation. The exploitation pattern fits within the broader category of denial-of-service vulnerabilities that leverage parsing characteristics to consume excessive computational resources. Organizations using reactive frameworks and streaming JSON parsers should immediately update to patched versions of Jackson core libraries to mitigate this risk and ensure proper constraint enforcement during asynchronous data processing operations.
The security implications extend beyond simple memory consumption, as this vulnerability can potentially lead to complete system instability through heap exhaustion attacks. The asynchronous nature of modern web applications makes this particularly dangerous since attackers can leverage concurrent connection handling capabilities to amplify the impact of resource exhaustion. Proper mitigation requires not only updating library versions but also implementing monitoring for unusual memory allocation patterns in parsing components and ensuring that StreamReadConstraints are properly configured with appropriate limits for production environments.
The vulnerability underscores the complexity of asynchronous parsing logic and the critical importance of comprehensive testing across all code paths, particularly in security-sensitive applications handling untrusted input streams. The mismatch between expected behavior and actual implementation demonstrates how seemingly minor oversights in validation routines can create significant security risks in widely-used libraries that form foundational components of modern application architectures.