FasterXML jackson-core up to 3.2.0 Non-blocking parser _startPositiveNumber heap-based overflow

Summaryinfo

A vulnerability was found in FasterXML jackson-core up to 2.18.7/2.21.3/2.22.0/3.1.3/3.2.0. It has been rated as problematic. This affects the function _startPositiveNumber of the component Non-blocking parser. Performing a manipulation results in heap-based overflow. This vulnerability was named CVE-2026-68494. The attack may be initiated remotely. There is no available exploit.

Detailsinfo

A vulnerability, which was classified as problematic, was found in FasterXML jackson-core up to 2.18.7/2.21.3/2.22.0/3.1.3/3.2.0. This affects the function _startPositiveNumber of the component Non-blocking parser. The manipulation with an unknown input leads to a heap-based overflow vulnerability. CWE is classifying the issue as CWE-122. A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). This is going to have an impact on availability. The summary by CVE is:

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.

The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-68494 since 07/30/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details are known, but no exploit is available.

Upgrading to version 2.18.6 or 2.21.1 eliminates this vulnerability.

The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2026-52703). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Programming Language Software

Vendor

• FasterXML

Name

• jackson-core

Version

• 2.0
• 2.1
• 2.2
• 2.3
• 2.4
• 2.5
• 2.6
• 2.7
• 2.8
• 2.9
• 2.10
• 2.11
• 2.12
• 2.13
• 2.14
• 2.15
• 2.16
• 2.17
• 2.18
• 2.18.0
• 2.18.1
• 2.18.2
• 2.18.3
• 2.18.4
• 2.18.5
• 2.18.6
• 2.18.7
• 2.19
• 2.20
• 2.21
• 2.21.0
• 2.21.1
• 2.21.2
• 2.21.3
• 2.22.0
• 3.0
• 3.1
• 3.1.0
• 3.1.1
• 3.1.2
• 3.1.3
• 3.2.0

License

• open-source

Website

• Product: https://github.com/FasterXML/jackson-core/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion