The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses. Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond the ability to submit data for parsing are required. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. 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-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.

The remote openSUSE 16 host has packages installed that are affected by multiple vulnerabilities as referenced in the openSUSE-SU-2026:22034-1 advisory.

    - 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

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength
    constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to
    an application that uses the async parser API can supply a number token of arbitrary length, leading to
    excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The
    synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on
    which parsing API the application uses. Root cause: the async parsing path in
    NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods.
    Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without
    any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call
    resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and
    validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never
    enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily
    long number to an application using the async parser (for example a Spring WebFlux or other reactive
    application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application
    subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in
    O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond
    the ability to submit data for parsing are required. This issue affects
    com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0,
    and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. 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-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0. (CVE-2026-18401)

The remote SUSE Linux SLED15 / SLED_SAP15 / SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2026:4394-1 advisory.

    - 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 `String`s 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 Object property names added to 'stringref'      reference table twice

    Changes for jackson-modules-base:

    - Update to 2.18.11

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of Adobe Experience Manager installed on the remote host is prior to 2026.8.0, 6.5.3. It is, therefore, affected by multiple vulnerabilities as referenced in the APSB26-98 advisory.

  - Critical XXE in Apache Tika tika-core (1.13-3.2.1), tika-pdf-module (2.0.0-3.2.1) and tika-parsers     (1.13-1.28.5) modules on all platforms allows an attacker to carry out XML External Entity injection via a     crafted XFA file inside of a PDF. This CVE covers the same vulnerability as in CVE-2025-54988. However,     this CVE expands the scope of affected packages in two ways. First, while the entrypoint for the     vulnerability was the tika-parser-pdf-module as reported in CVE-2025-54988, the vulnerability and its fix     were in tika-core. Users who upgraded the tika-parser-pdf-module but did not upgrade tika-core to >= 3.2.2     would still be vulnerable. Second, the original report failed to mention that in the 1.x Tika releases,     the PDFParser was in the org.apache.tika:tika-parsers module. (CVE-2025-66516)

  - The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength     constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to     an application that uses the async parser API can supply a number token of arbitrary length, leading to     excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The     synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on     which parsing API the application uses. Root cause: the async parsing path in     NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods.
    Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without     any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call     resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and     validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never     enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily     long number to an application using the async parser (for example a Spring WebFlux or other reactive     application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application     subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in     O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond     the ability to submit data for parsing are required. This issue affects     com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0,     and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. 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-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0. (CVE-2026-18401)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-2067 advisory.

    The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength     constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to     an application that uses the async parser API can supply a number token of arbitrary length, leading to     excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.



    The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently     depending on which parsing API the application uses.



    Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the     number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate     digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token.
    _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where     validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped,     maxNumberLength is never enforced on the async code path.



    Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using     the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded     allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls     getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger     parsing, causing CPU-based denial of service.



    No privileges or user interaction beyond the ability to submit data for parsing are required.



    This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from     2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.



    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-72hv-8253-57qq records the lower bound of the affected 2.x     range as 2.0.0. (CVE-2026-18401)

    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. (CVE-2026-68494)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength     constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to     an application that uses the async parser API can supply a number token of arbitrary length, leading to     excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The     synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on     which parsing API the application uses. Root cause: the async parsing path in     NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods.
    Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without     any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call     resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and     validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never     enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily     long number to an application using the async parser (for example a Spring WebFlux or other reactive     application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application     subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in     O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond     the ability to submit data for parsing are required. This issue affects     com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0,     and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. 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-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0. (CVE-2026-18401)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
364341	openSUSE 16: jackson-annotations / jackson-annotations-javadoc / jackson-core / etc (openSUSE-SU-2026:22034-1)	Nessus	SuSE Local Security Checks	Local	high
457563	Echo: com.fasterxml.jackson.core:jackson-core: security update to 2.18.6tools.jackson.core:jackson-core: security update to 3.1.0	Tenable Cloud Security	Echo Local Security Checks	Local	medium
457563	Echo: com.fasterxml.jackson.core:jackson-core: security update to 2.18.6tools.jackson.core:jackson-core: security update to 3.1.0	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	medium
351412	SUSE SLED15: jackson-annotations / jackson-core / jackson-databind / etc (SUSE-SU-2026:4394-1)	Nessus	SuSE Local Security Checks	Local	high
344294	Adobe Experience Manager 6.5.0 < 6.5.3 / 2026.7.0 < 2026.8.0 Multiple Vulnerabilities (APSB26-98)	Nessus	Misc.	Remote	medium
337219	Amazon Linux 2023 : jackson-core (ALAS2023-2026-2067)	Nessus	Amazon Linux Local Security Checks	Local	high
332069	Linux Distros Unpatched Vulnerability : CVE-2026-18401	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-18401

medium

Tenable Plugins

high

medium

medium

high

medium

high

medium