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

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 remote Redhat Enterprise Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2026:53644 advisory.

    Red Hat JBoss Enterprise Application Platform 7 is a platform for Java applications based on the WildFly     application runtime. This release of Red Hat JBoss Enterprise Application Platform 7.4.25 serves as a     replacement for Red Hat JBoss Enterprise Application Platform 7.4.24, and includes bug fixes and     enhancements. See the Red Hat JBoss Enterprise Application Platform 7.4.25 Release Notes for information     about the most significant bug fixes and enhancements included in this release.

    Security Fix(es):

    * netty-codec-redis: Netty: Denial of Service via malicious Redis array header (CVE-2026-50011)

    * netty-handler: Netty: Denial of Service due to eager buffer allocation in TLS handshake (CVE-2026-45416)

    * netty-codec-redis: netty-codec-redis: Denial of Service via crafted Redis payload with deeply nested     arrays (CVE-2026-44250)

    * netty-codec-redis: netty-codec-redis: Denial of Service via crafted Redis payloads (CVE-2026-44890)

    * netty-transport-sctp: Netty-transport-sctp: Denial of Service due to unbounded memory growth from     SctpMessage fragments (CVE-2026-46340)

    * netty-resolver-dns: Netty: Information disclosure and data manipulation due to improper CNAME record     validation (CVE-2026-45674)

    * netty-handler: Netty: Improper trust manager handling leads to hostname verification bypass     (CVE-2026-50010)

    * netty-codec-redis: Netty's Lack of Lifecycle Cleanup Leads to Pooled ByteBuf Leak in     RedisArrayAggregator (CVE-2026-48006)

    * netty-resolver-dns: Netty has Insufficient Bailiwick Validation for NS Records (CVE-2026-47691)

    * netty-codec-haproxy: Netty HAProxy PROXY protocol v2 codec: Denial of Service via memory leak from     crafted PROXY protocol headers (CVE-2026-48059)

    * netty-codec-http2: netty-codec-http2: Denial of Service due to resource leak (CVE-2026-48043)

    * netty-codec-haproxy: Netty-codec-haproxy: Denial of Service via malformed HAProxy message     (CVE-2026-44893)

    * netty-codec-http: Netty: Request smuggling via malformed Transfer-Encoding parsing (CVE-2026-42585)

    * netty-codec-http2: Netty: Denial of Service via unbounded memory allocation in HTTP content     decompression (CVE-2026-42587)

    * netty-codec-http: Netty: Denial of Service via unbounded memory allocation in HTTP content decompression     (CVE-2026-42587)

    * netty-codec-http: Netty: HTTP request smuggling via URI manipulation and CRLF injection (CVE-2026-41417)

    * netty-handler-proxy: Netty: HTTP Header Injection via HttpProxyHandler Disabled Validation     (CVE-2026-42578)

    * netty-codec-http: Netty: HTTP Request Smuggling due to improper handling of conflicting HTTP/1.0 headers     (CVE-2026-42581)

    * netty-codec-http: Netty: Incorrect HTTP response parsing leads to data confusion (CVE-2026-42584)

    * netty-codec-dns: Netty: High integrity impact due to improper DNS domain name constraint enforcement     (CVE-2026-42579)

    * picketlink-federation: auth bypass in Picketlink SAML unsolicited-response (CVE-2026-10579)

    * bcprov-jdk18on: LDAP injection vulnerability in LDAPStoreHelper.java (CVE-2026-0636)

    * bcprov-jdk15on: LDAP injection vulnerability in LDAPStoreHelper.java (CVE-2026-0636)

    * bcprov-jdk15: LDAP injection vulnerability in LDAPStoreHelper.java (CVE-2026-0636)

    * bcprov-jdk12: LDAP injection vulnerability in LDAPStoreHelper.java (CVE-2026-0636)

    * bcpg-jdk18on: unbounded PGP AEAD chunk size leads to pre-auth resource exhaustion (CVE-2026-3505)

    * bcpg-jdk15on: unbounded PGP AEAD chunk size leads to pre-auth resource exhaustion (CVE-2026-3505)

    * bcpkix-jdk18on: PKIX draft CompositeVerifier accepts empty signature sequence as valid (CVE-2026-5588)

    * bcpkix-jdk15on: PKIX draft CompositeVerifier accepts empty signature sequence as valid (CVE-2026-5588)

    * bcprov-jdk18on: GOSTCTR implementation unable to process more than 255 blocks correctly (CVE-2025-14813)

    * bcprov-jdk15on: GOSTCTR implementation unable to process more than 255 blocks correctly (CVE-2025-14813)

    * bcprov-jdk15: GOSTCTR implementation unable to process more than 255 blocks correctly (CVE-2025-14813)

    * bcprov-jdk12: GOSTCTR implementation unable to process more than 255 blocks correctly (CVE-2025-14813)

    * bcprov-jdk15: private key leakage via non-constant time comparisons (CVE-2026-5598)

    * bcprov-jdk12: private key leakage via non-constant time comparisons (CVE-2026-5598)

    * artemis-server: Apache Artemis, Apache ActiveMQ Artemis: Message injection and exfiltration due to     missing authentication (CVE-2026-27446)

    * undertow-core: Undertow: Authentication Bypass via AJP ssl_cert/is_ssl Forgery (CVE-2026-15554)

    * wildfly-clustering-infinispan-marshalling: Jboss Deserialization RCE via Unfiltered River Unmarshaller     (CVE-2026-15555)

    * picketlink-federation: picketlink SAML 2.0 auth bypass via missing assertions (CVE-2026-15556)

    * openjdk-orb: unauthed class loading via IIOP in EAP (CVE-2026-15560)

    * undertow-core: OOM via missing limits in chunked trailer in EAP's Undertow (CVE-2026-15561)

    * jboss-remoting: jboss-remoting: integer overflow in MessageReader leads to pre-authentication denial of     service (CVE-2026-15562)

    * wildfly-iiop-openjdk: Missing authentication on EAP's IIOP NameService leads to MITM or DoS     (CVE-2026-15563)

    * jsf-impl: mojarra: Unauthenticated RCE in EAP JSF applications via EL injection in ui:include     (CVE-2026-46581)

    * netty-handler: netty-handler: IPv6 subnet rule bypass due to incorrect masking operation     (CVE-2026-44249)

    * jackson-core: Denial of Service via incomplete fix in async JSON parser (CVE-2026-68494)

    For more details about the security issue(s), including the impact, a CVSS     score, acknowledgments, and other related information, refer to the CVE page(s)     listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux 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 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-68494)

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

ID	Name	Product	Family	Type	Severity
337219	Amazon Linux 2023 : jackson-core (ALAS2023-2026-2067)	Nessus	Amazon Linux Local Security Checks	Local	high
334631	RHEL 7 : Red Hat JBoss Enterprise Application Platform 7.4.25 security pdate (Important) (RHSA-2026:53644)	Nessus	Red Hat Local Security Checks	Local	critical
332786	Linux Distros Unpatched Vulnerability : CVE-2026-68494	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-68494

high

Tenable Plugins

high

critical

high