CVE-2026-68498 is a high-severity vulnerability in FasterXML jackson-core affecting versions from 2.16.0 onward. It involves uncontrolled resource consumption due to improper enforcement of the maxNameLength constraint when parsing JSON property names from character-based inputs (e.g., String, Reader, char[]). This allows an attacker to cause excessive memory allocation, potentially exhausting heap memory and crashing the process. Byte-input parsers are not affected. The issue arises because the name length check is delayed until after a large buffer allocation, exceeding the intended limit. No authentication is required, and the default configuration is vulnerable.
CVE-2026-89425 is a high-severity vulnerability in FasterXML jackson-core affecting versions from 2.8.0 through 3.2.2 in various subranges. The issue arises in UTF8DataInputJsonParser._reportInvalidToken(), which accumulates malformed token text without any upper bound, leading to excessive memory use. This can cause the Java Virtual Machine to run out of memory and crash due to unbounded StringBuilder growth when processing large malformed tokens via the DataInput parsing path.
CVE-2026-89407 is a high-severity vulnerability in FasterXML jackson-core affecting versions from 2.17.0 through 3.2.1 in specified subranges. It involves inefficient regular expression complexity in the NumberInput.looksLikeValidNumber() method, causing quadratic time complexity when processing certain numeric string inputs. This can lead to denial-of-service conditions by exhausting server resources during JSON deserialization of numeric types. The issue does not exist before version 2.17.0 and has been fixed by replacing the problematic regex with a single-pass scan.
A vulnerability in tools.jackson.core:jackson-core affects its asynchronous JSON parser's handling of streamed numeric input. The issue is an incomplete fix for a prior CVE, allowing an attacker to bypass the maxNumberLength constraint by streaming JSON numbers in many small chunks without terminators. This causes excessive memory allocation, potentially exhausting JVM heap memory. The flaw impacts versions from 2.15.0 through 2.18.7, 2.19.0 through 2.21.3, 2.22.0, and 3.0.0 through 3.1.3 and 3.2.0. Synchronous parsers and async parsers on complete input are not affected. Exploitation requires only the ability to stream data to a parsing endpoint, with no privileges or user interaction needed.
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, and from 2.19.0 through 2.21.3, and tools.jackson.core:jackson-core from 3.0.0 through 3.1.3. 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 2.22.x and 3.2.x release lines are not affected: those branches were created after the fix commit landed on 2026-05-21 and therefore contain it from their initial releases (2.22.0, tagged 2026-06-03, and 3.2.0, tagged 2026-06-08).
CVE-2026-18401 is a medium severity vulnerability in FasterXML jackson-core affecting the asynchronous JSON parser. The async parser does not enforce the maxNumberLength constraint, allowing an attacker to submit JSON with arbitrarily long number tokens. This leads to excessive memory allocation and potential CPU exhaustion, causing denial of service. The synchronous parser is not affected as it enforces this limit correctly. No privileges or user interaction beyond submitting JSON data are required. The issue affects jackson-core versions 2.15.0 through 2.18.5, 2.19.0 through 2.21.0, and 3.0.0 through 3.0.x. Patch status is not confirmed; no official fix or remediation level is stated in the vendor advisory.
An incomplete fix in jackson-core's async JSON parser allows an attacker to bypass the maxNumberLength limit by streaming JSON numbers in many small chunks without terminators, causing unbounded memory allocation. This affects versions prior to 2.18.8, certain 2.19.x and 2.21.x versions, and some 3.x versions. The vulnerability leads to memory exhaustion due to unchecked growth of the internal text buffer during integer parsing in non-blocking mode.
A vulnerability in the async JSON parser of jackson-core allows bypassing the maxNumberLength constraint, enabling parsing of arbitrarily long numbers. This leads to excessive memory allocation and potential CPU exhaustion, causing a Denial of Service (DoS). The synchronous parser enforces the limit correctly, but the async parser fails to validate number length due to skipped checks in its code path. This inconsistency creates a resource exhaustion risk when processing large numeric JSON values asynchronously.