CVE-2026-68494

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-r7wm-3cxj-wff9. This link is maintained to preserve external references.

Original Description

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.

Summary

The fix released in jackson-core 2.18.6 and 2.21.1 for GHSA-72hv-8253-57qq (Number Length Constraint Bypass in Async Parser, published 2026-02-28) is incomplete. The fix commit b0c428e6 (#1555) wired validateIntegerLength into a new _setIntLength helper and called it at every place where the integer portion of a number is decided (terminator byte arrived, . / e/E seen, end-of-feed inside a fully-buffered value). It did not call it on the much more attacker-relevant path: "ran out of input while still inside MINOR_NUMBER_INTEGER_DIGITS, return NOT_AVAILABLE to caller".

As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, can keep the parser inside MINOR_NUMBER_INTEGER_DIGITS indefinitely. _textBuffer.expandCurrentSegment() grows on every chunk, and validateIntegerLength is never invoked. The accumulator is only gated by maxStringLength (20 MiB default) — a ~20,000x amplification of the documented maxNumberLength (1000 default).

This is the same vulnerability class, same advisory wording ("Memory Exhaustion: Unbounded allocation in TextBuffer from excessively long numbers"), same parser class — just the streaming path the original fix didn't cover. The fix to the fraction path is correct (see _finishFloatFraction at line 1834-1837 of NonBlockingUtf8JsonParserBase.java in 2.18.6, where _setFractLength(fractLen) IS called before the NOT_AVAILABLE return); the equivalent call is missing from every integer-digit path.

Affected versions

Verified on the patched releases:

• com.fasterxml.jackson.core:jackson-core 2.18.6
• com.fasterxml.jackson.core:jackson-core 2.21.1

Structurally identical code in tools.jackson.core 3.0.x / 3.1.x — same NonBlockingUtf8JsonParserBase class, same _setIntLength rollout, same NOT_AVAILABLE returns without validation. Not retested but presumed vulnerable.

Affected code

src/main/java/com/fasterxml/jackson/core/json/async/NonBlockingUtf8JsonParserBase.java in 2.18.6 / 2.21.1.

Site 1 — _startPositiveNumber(int ch) lines 1320-1330:

if (outPtr >= outBuf.length) {
    // NOTE: must expand to ensure contents all in a single buffer (to keep
    // other parts of parsing simpler)
    outBuf = _textBuffer.expandCurrentSegment();
}
outBuf[outPtr++] = (char) ch;
if (++_inputPtr >= _inputEnd) {
    _minorState = MINOR_NUMBER_INTEGER_DIGITS;
    _textBuffer.setCurrentLength(outPtr);
    return _updateTokenToNA();          // <-- no validateIntegerLength(outPtr)
}

Site 2 — _finishNumberIntegralPart lines 1691-1727:

protected JsonToken _finishNumberIntegralPart(char[] outBuf, int outPtr) throws IOException {
    int negMod = _numberNegative ? -1 : 0;

    while (true) {
        if (_inputPtr >= _inputEnd) {
            _minorState = MINOR_NUMBER_INTEGER_DIGITS;
            _textBuffer.setCurrentLength(outPtr);
            return _updateTokenToNA();    // <-- no validateIntegerLength(outPtr + negMod)
        }
        int ch = getByteFromBuffer(_inputPtr) & 0xFF;
        if (ch < INT_0) {
            if (ch == INT_PERIOD) {
                _setIntLength(outPtr+negMod);   // <-- validated here
                ++_inputPtr;
                return _startFloat(outBuf, outPtr, ch);
            }
            break;
        }
        if (ch > INT_9) {
            if ((ch | 0x20) == INT_e) {
                _setIntLength(outPtr+negMod);   // <-- validated here
                ++_inputPtr;
                return _startFloat(outBuf, outPtr, ch);
            }
            break;
        }
        ++_inputPtr;
        if (outPtr >= outBuf.length) {
            outBuf =…

Red Hat Lightwell has released com.fasterxml.jackson.core:jackson-core 2.17.3.rhlw-00005 with backported fixes for CVE-2026-18401, CVE-2026-68494, CVE-2026-89407, and CVE-2026-89425.

CVE-2026-18401: jackson-core: Number length constraint bypass in non-blocking (async) JSON parser leads to potential denial of service

CVE-2026-68494: jackson-core: Async parser maxNumberLength bypass via chunked digit accumulation (incomplete fix for CVE-2026-18401 / GHSA-72hv-8253-57qq)

CVE-2026-89407: jackson-core: quadratic backtracking in NumberInput.PATTERN_FLOAT via looksLikeValidNumber() enables ReDoS

CVE-2026-89425: jackson-core: UTF8DataInputJsonParser._reportInvalidToken() does not honor maxErrorTokenLength, allowing unbounded StringBuilder growth

This patched artifact is a drop-in replacement for com.fasterxml.jackson.core:jackson-core 2.17.3 from Maven Central.

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).

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 4 CVEs. Fixed in 2.17.2-tuxcare.1.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 6 CVEs. Fixed in 2.17.1-tuxcare.1.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 4 CVEs. Fixed in 2.17.3-tuxcare.2.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 5 CVEs. Fixed in 2.14.2-tuxcare.3.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 5 CVEs. Fixed in 2.14.1-tuxcare.2.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 6 CVEs. Fixed in 2.13.2-tuxcare.1.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 6 CVEs. Fixed in 2.13.4-tuxcare.1.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 2 CVEs. Fixed in 2.18.0-tuxcare.1.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 3 CVEs. Fixed in 2.16.1-tuxcare.1.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 5 CVEs. Fixed in 2.15.0-tuxcare.1.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 4 CVEs. Fixed in 2.13.3-tuxcare.1.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 3 CVEs. Fixed in 2.18.4.1-tuxcare.2.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 6 CVEs. Fixed in 2.20.1-tuxcare.1.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 2 CVEs. Fixed in 2.15.4-tuxcare.2.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 1 CVE. Fixed in 2.13.5-tuxcare.2.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 1 CVE. Fixed in 2.15.2-tuxcare.2.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 1 CVE. Fixed in 2.15.3-tuxcare.2.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 1 CVE. Fixed in 2.14.3-tuxcare.2.

TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 2 CVEs. Fixed in 2.21.2-tuxcare.2.

These are all security issues fixed in the jackson-core-2.18.9-2.1 package on the GA media of openSUSE Tumbleweed.

This update for jackson-annotations, jackson-core, jackson-databind fixes the following issues:

• CVE-2026-18401: Number Length Constraint Bypass in Async Parser Can Lead to Potential Processing Time Issues (bsc#1273856).
• CVE-2026-19032: deserializer for java.nio.file.Path resolves attacker-supplied URIs without restricting the URI scheme (bsc#1277883).
• CVE-2026-68494: Async parser maxNumberLength bypass via chunked digit accumulation (bsc#1273857).
• CVE-2026-68497: An unauthenticated attacker can therefore submit a single request of a few megabytes (bsc#1280125).
• CVE-2026-68498: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641).
• CVE-2026-83557: incomplete PolymorphicTypeValidator denylist allows for arbitrary Comparable deserialization (bsc#1278008).
• CVE-2026-89407: Optimize NumberInput.looksLikeValidNumber (bsc#1282645).
• CVE-2026-89425: UTF8DataInputJsonParser._reportInvalidToken()lacks maxErrorTokenLength limit, which allows for unbounded StringBuilder growth and can lead to a DoS when malformed tokens are processed (bsc#1282505).
• CVE-2026-91776: TypeDeserializerBase._findDeserializer() caches the resolved deserializer under the raw, attacker- supplied type ID, which can lead to unbounded cache growth under certain configurations (bsc#1282491).
• CVE-2026-91777: forward-reference completion for @JsonIdentityInfo object IDs performs a linear scan of the pending- reference accumulator for every resolved ID, which can lead to quadratic CPU work during deserialization (bsc#1282492).

Changes for jackson-annotations:

• Update to 2.18.11

Changes for jackson-core:

• Update to 2.18.11

• #1649: Optimize NumberInput.looksLikeValidNumber (bsc#1282645, CVE-2026-89407)
• #1698: UTF8DataInputJsonParser does not honor maxErrorTokenLength when reporting an unrecognized token (bsc#1282505, CVE-2026-89425)
• #1642: Fix maxDocumentLength bypass in async parser single-feedInput() case [GHSA-2c4j-63jj-9fqr]
• #1643: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641, CVE-2026-68498) of async parser (bsc#1273857, CVE-2026-68494) non-blocking (async) parser (bsc#1273856, CVE-2026-18401)

Changes for jackson-databind:

• Update to 2.18.11

• #6185: Bracket unresolved IPv6 host name in InetSocketAddress serialization
• #6203: Prevent unbounded growth of type id cache in TypeDeserializer (bsc#1282491, CVE-2026-91776)
• #6204: Avoid quadratic forward-reference resolution in Collection/Map deserializers (bsc#1282492, CVE-2026-91777)
• #6099: Resolve classes without initialization in TypeFactory.findClass()
• #6116: Reject non-ASCII digits in InetAddress literal validation
• #6127: Add StreamReadConstraints number len constraint to javax.xml.datatype.XMLGregorianCalendar and javax.xml.datatype.Duration (bsc#1280125, CVE-2026-68497)
• #6129: Limit the supported URL schemes for java.nio.file.Path deserialization (bsc#1277883, CVE-2026-19032)
• #6156: Add java.lang.Comparable in set of unsafe polymorphic base types (bsc#1278008, CVE-2026-83557)
• #6165: Apply number length limits to BigDecimal/BigInteger/ /Double/Float Map keys

Root has patched GHSA-642r-3gj9-2pj5 in the tools.jackson.core:jackson-core package for Root:Maven. Multiple fixed versions available.

This update for jackson-annotations, jackson-core, jackson-databind fixes the following issues:

• CVE-2026-18401: Number Length Constraint Bypass in Async Parser Can Lead to Potential Processing Time Issues (bsc#1273856).
• CVE-2026-19032: deserializer for java.nio.file.Path resolves attacker-supplied URIs without restricting the URI scheme (bsc#1277883).
• CVE-2026-68494: Async parser maxNumberLength bypass via chunked digit accumulation (bsc#1273857).
• CVE-2026-68497: An unauthenticated attacker can therefore submit a single request of a few megabytes (bsc#1280125).
• CVE-2026-68498: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641).
• CVE-2026-83557: incomplete PolymorphicTypeValidator denylist allows for arbitrary Comparable deserialization (bsc#1278008).
• CVE-2026-89407: Optimize NumberInput.looksLikeValidNumber (bsc#1282645).
• CVE-2026-89425: UTF8DataInputJsonParser._reportInvalidToken()lacks maxErrorTokenLength limit, which allows for unbounded StringBuilder growth and can lead to a DoS when malformed tokens are processed (bsc#1282505).
• CVE-2026-91776: TypeDeserializerBase._findDeserializer() caches the resolved deserializer under the raw, attacker- supplied type ID, which can lead to unbounded cache growth under certain configurations (bsc#1282491).
• CVE-2026-91777: forward-reference completion for @JsonIdentityInfo object IDs performs a linear scan of the pending- reference accumulator for every resolved ID, which can lead to quadratic CPU work during deserialization (bsc#1282492).

Changes for jackson-annotations:

• Update to 2.18.11

Changes for jackson-core:

• Update to 2.18.11

• #1649: Optimize NumberInput.looksLikeValidNumber (bsc#1282645, CVE-2026-89407)
• #1698: UTF8DataInputJsonParser does not honor maxErrorTokenLength when reporting an unrecognized token (bsc#1282505, CVE-2026-89425)
• #1642: Fix maxDocumentLength bypass in async parser single-feedInput() case [GHSA-2c4j-63jj-9fqr]
• #1643: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641, CVE-2026-68498) of async parser (bsc#1273857, CVE-2026-68494) non-blocking (async) parser (bsc#1273856, CVE-2026-18401)

Changes for jackson-databind:

• Update to 2.18.11

• #6185: Bracket unresolved IPv6 host name in InetSocketAddress serialization
• #6203: Prevent unbounded growth of type id cache in TypeDeserializer (bsc#1282491, CVE-2026-91776)
• #6204: Avoid quadratic forward-reference resolution in Collection/Map deserializers (bsc#1282492, CVE-2026-91777)
• #6099: Resolve classes without initialization in TypeFactory.findClass()
• #6116: Reject non-ASCII digits in InetAddress literal validation
• #6127: Add StreamReadConstraints number len constraint to javax.xml.datatype.XMLGregorianCalendar and javax.xml.datatype.Duration (bsc#1280125, CVE-2026-68497)
• #6129: Limit the supported URL schemes for java.nio.file.Path deserialization (bsc#1277883, CVE-2026-19032)
• #6156: Add java.lang.Comparable in set of unsafe polymorphic base types (bsc#1278008, CVE-2026-83557)
• #6165: Apply number length limits to BigDecimal/BigInteger/ /Double/Float Map keys

This update for jackson-annotations, jackson-bom, jackson-core, jackson-databind, jackson-dataformat-xml, jackson-dataformats-binary, jackson-modules-base fixes the following issues:

• CVE-2026-18401: Number Length Constraint Bypass in Async Parser Can Lead to Potential Processing Time Issues (bsc#1273856).
• CVE-2026-68494: Async parser maxNumberLength bypass via chunked digit accumulation (bsc#1273857).
• CVE-2026-68495: Ensure maxNameLength limit enforced for CBOR parser (bsc#1282639).
• CVE-2026-68496: Ensure maxNameLength limit enforced for Smile parser (bsc#1282640).
• CVE-2026-68498: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641).
• CVE-2026-89407: Optimize NumberInput.looksLikeValidNumber (bsc#1282645).
• CVE-2026-89425: UTF8DataInputJsonParser._reportInvalidToken()lacks maxErrorTokenLength limit, which allows for unbounded StringBuilder growth and can lead to a DoS when malformed tokens are processed (bsc#1282505).

Changes for jackson-annotations:

• Update to 2.18.11

Changes for jackson-bom:

• Update to 2.18.11

Changes for jackson-core:

• Update to 2.18.11

• #1649: Optimize NumberInput.looksLikeValidNumber (bsc#1282645, CVE-2026-89407)
• #1698: UTF8DataInputJsonParser does not honor maxErrorTokenLength when reporting an unrecognized token (bsc#1282505, CVE-2026-89425)
• #1642: Fix maxDocumentLength bypass in async parser single-feedInput() case [GHSA-2c4j-63jj-9fqr]
• #1643: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641, CVE-2026-68498) of async parser (bsc#1273857, CVE-2026-68494) non-blocking (async) parser (bsc#1273856, CVE-2026-18401)

Changes for jackson-databind:

• Update to 2.18.11

• #6185: Bracket unresolved IPv6 host name in InetSocketAddress serialization
• #6203: Prevent unbounded growth of type id cache in TypeDeserializer (bsc#1282491, CVE-2026-91776)
• #6204: Avoid quadratic forward-reference resolution in Collection/Map deserializers (bsc#1282492, CVE-2026-91777)
• #6099: Resolve classes without initialization in TypeFactory.findClass()
• #6116: Reject non-ASCII digits in InetAddress literal validation
• #6127: Add StreamReadConstraints number len constraint to javax.xml.datatype.XMLGregorianCalendar and javax.xml.datatype.Duration (bsc#1280125, CVE-2026-68497)
• #6129: Limit the supported URL schemes for java.nio.file.Path deserialization (bsc#1277883, CVE-2026-19032)
• #6156: Add java.lang.Comparable in set of unsafe polymorphic base types (bsc#1278008, CVE-2026-83557)
• #6165: Apply number length limits to BigDecimal/BigInteger/ /Double/Float Map keys

Changes for jackson-dataformat-xml:

• Update to 2.18.11

• Fix build to avoid past-JDK-8 bytecode generation
• #891: Enforce StreamReadConstraints.maxNestingDepth in FromXmlParser

Changes for jackson-dataformats-binary:

• Update to 2.18.11

• #783: (protobuf) Support StreamReadConstraints.maxDocumentLength in ProtobufParser
• #785: (avro) Support StreamReadConstraints.maxDocumentLength and maxTokenCount in Avro parser
• #803: (ion) Support StreamReadConstraints.maxNestingDepth in Ion parser (partial fix for #358)
• #805: (ion) Support StreamReadConstraints.maxDocumentLength in Ion parser (partial fix for #358)
• #725: (cbor) Ensure maxNameLength limit enforced for CBOR parser (bsc#1282639, CVE-2026-68495)
• #726: (smile) Ensure maxNameLength limit enforced for Smile parser (bsc#1282640, CVE-2026-68496)
• #727: (cbor) CBORParser.nextFieldName(SerializableString) confuses 5-bit length marker 23 with 24 ('1-byte length suffix follows')
• #728: (cbor) CBORParser.nextFieldName(SerializableString) consumes Object entry slot twice on fast-path miss, truncating definite-length Objects
• #733: (cbor) Long Strings not added to 'stringref' reference table, breaking following references
• #735: (cbor) 'stringref' property-name paths pass 5-bit length marker instead of actual length to shouldReferenceString()
• #736: (cbor) Long…