Intel

CVE-2026-68494

Red Hat Security Advisory: Release of Red Hat OpenShift Developer Tools - Openshift Jenkins 4.20 security update.

highEPSS 0.4 %

Beschreibung

Die Behebung in jackson-core 2.18.6 und 2.21.1 für CVE-2026-18401 (GHSA-72hv-8253-57qq, Umgehung der Längenbeschränkung im nicht-blockierenden Parser) ist unvollständig. Dieser Eintrag behandelt die verbleibende Umgehung. Die frühere Behebung verband validateIntegerLength() mit einer neuen _setIntLength()-Hilfsfunktion und rief sie überall auf, wo der Zahlenanteil eines Wertes entschieden wird: ein Terminierungsbyte tritt ein, ein '.' oder 'e'/'E' erscheint, oder die Eingabe endet innerhalb eines vollständig gepufferten Werts. Sie wurde nicht auf dem Angreifer-relevanten Pfad aufgerufen, bei dem der Parser während des Verbleibs im MINOR_NUMBER_INTEGER_DIGITS-Zustand ausgeht und NOT_AVAILABLE an den Aufrufer zurückgibt. Daher kann ein Angreifer JSON-Daten in viele kleine Teile zu einem nicht-blockierenden Parser streamen, ohne jemals ein Terminierungsbyte zu senden, wodurch der Parser unendlich im MINOR_NUMBER_INTEGER_DIGITS-Zustand bleibt. _textBuffer.expandCurrentSegment() vergrößert den Akkumulator bei jedem Teil, während validateIntegerLength() nie aufgerufen wird. Der Akkumulator ist nur durch maxStringLength (20 MiB standardmäßig) und nicht durch maxNumberLength (1000 standardmäßig) begrenzt, was eine Verstärkung von ungefähr 20.000-fach über die dokumentierte Grenze darstellt. Da Java-Char-Werte zwei Bytes einnehmen, kann eine einzelne Verbindung auf etwa 40 MiB des Heaps anwachsen, bevor der Validator schließlich ausgelöst wird, wenn der Wert abgeschlossen ist. Der entsprechende Code für den Bruchpfad ist korrekt: _finishFloatFraction() ruft _setFractLength() vor seinem NOT_AVAILABLE-Rückgabewert auf. Der fehlende Aufruf betrifft die Ziffernwege in _startPositiveNumber(), _startNegativeNumber() und _finishNumberIntegralPart() in NonBlockingUtf8JsonParserBase. Auswirkung: Reaktive Frameworks wie Spring WebFlux/Reactor, Quarkus, Helidon und Vert.x füttern eingehende HTTP- oder gRPC-Bytes an den asynchronen Parser, sobald sie eintreffen, was genau die gestreamte Form erfordert. Operatoren, die StreamReadConstraints.maxNumberLength erwarten, um den Speicher pro Zahlwert zu begrenzen, erhalten diese Garantie nicht; der Speicher akkumuliert pro gleichzeitiger Verbindung und durch Angreifer-gesteuerte Parallelität kann der JVM-Speicher erschöpft werden. Die synchronen Parser (UTF8StreamJsonParser, ReaderBasedJsonParser) und der asynchrone Parser bei vollständigem Eingang sind nicht betroffen. Die Ausnutzung erfordert nur die Fähigkeit, Daten zu einem Parsing-Endpunkt zu streamen; keine Berechtigungen oder Benutzerinteraktionen sind erforderlich. Dieses Problem betrifft com.fasterxml.jackson.core:jackson-core von Version 2.15.0 bis 2.18.7 und von 2.19.0 bis 2.21.3, sowie tools.jackson.core:jackson-core von 3.0.0 bis 3.1.3. Versionen vor 2.15.0 sind nicht betroffen, da StreamReadConstraints -- die die maxNumberLength-Einstellung definiert -- erst in jackson-core 2.15.0 eingeführt wurde und daher keine solche Beschränkung in früheren Veröffentlichungen umgangen werden kann. Beachten Sie, dass GHSA-r7wm-3cxj-wff9 den betroffenen 2.x-Bereich ohne untere Grenze angibt. Die Release-Linien 2.22.x und 3.2.x sind nicht betroffen: Diese Zweige wurden erstellt, nachdem der Behebungskommit am 21.05.2026 eingegangen war, und enthalten daher die Behebung ab ihren ersten Veröffentlichungen (2.22.0, gekennzeichnet am 03.06.2026, und 3.2.0, gekennzeichnet am 08.06.2026).

Quelle: REDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFREDHAT_CSAFBSIBSI_CSAFREDHAT_CSAFREDHAT_CSAFCVELISTV5NVD

Metriken

Severity
high
Priority-Score
138.35
KEV-Status
—
Exploit-Reife
kein öffentlicher PoC bekannt
XIEM Effective CVSS
8.7
Quelle: nvd-v4
CVSS v3
—
CVSS v4
8.7
EPSS-Perzentil
30.6 %
Erhöht — CVE ist relevanter als mindestens 10 % der heute bewerteten CVEs.
EPSS-Score
0.4 %
Niedrig — Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
Veröffentlicht
2026-08-26 10:57 UTC
CWE
CWE-770

Weakness-Klassen (CWE)

  • CWE-770Base

    Allocation of Resources Without Limits or Throttling

    The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

    cwe.mitre.org →

Re-Analyse & Statuswechsel

Chronologie der NVD-Audit-Events für diese CVE — Reanalyses, CVSS-Updates, CPE-Diffs.

  1. CVE Modified2026-08-05 02:16 UTC· 36c7be3b-2937-45df-85ea-ca7133ea542c
    • Affected: jackson-core, jackson-core → jackson-core, jackson-core
    • 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. → 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).
  2. CVE Modified2026-08-04 19:16 UTC· 134c704f-9b21-4f2e-91b3-4a467353bcc0
    • Reference: https://github.com/FasterXML/jackson-core/security/advisories/GHSA-r7wm-3cxj-wff9
    • SSVC: {"id":"CVE-2026-68494","role":"CISA Coordinator","options":[{"exploitation":"poc"},{"automatable":"yes"},{"technicalI…
  3. New CVE Received2026-08-04 15:16 UTC· 36c7be3b-2937-45df-85ea-ca7133ea542c
    • Affected: jackson-core, jackson-core
    • 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.
    • CVSS V4.0: AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
    • CWE: CWE-770

Betroffene Produkte

Aus der Hersteller-/CERT-Meldung extrahierte Produkte und Versionsbereiche. Ein Version-Range wie „<4.14.6“ impliziert die Update-Empfehlung „auf 4.14.6 oder höher aktualisieren“.

  • Apache

    Camel4.18

  • apache

    httpclient

  • apache

    mina

  • Atlassian

    BambooData Center LTS 10.2.22

  • Atlassian

    BambooData Center LTS 12.1.10

  • Atlassian

    BitbucketData Center 10.4.2

  • Atlassian

    BitbucketData Center LTS 10.2.6

  • Atlassian

    BitbucketData Center LTS 9.4.23

  • Atlassian

    ConfluenceData Center LTS 10.2.15

  • Atlassian

    ConfluenceData Center LTS 9.2.23

  • Atlassian

    Crucible4.9.13

  • Atlassian

    Fisheye4.9.13

  • Atlassian

    JiraData Center LTS 10.3.24

  • Atlassian

    JiraData Center LTS 11.3.10

  • bitnami

    jenkins2.556.0

  • bitnami

    jenkins2.569.0

  • codehaus-plexus

    plexus-utils4.0.0 – 4.0.3

  • codehaus-plexus

    plexus-utils3.6.1

  • eclipse

    jetty10.0.0 – 10.0.28

  • eclipse

    jetty11.0.0 – 11.0.28

  • eclipse

    jetty12.0.0 – 12.0.32

  • eclipse

    jetty12.0.0 – 12.0.33

  • eclipse

    jetty12.1.0 – 12.1.6

  • eclipse

    jetty12.1.0 – 12.1.7

Quellen & Referenzen

Verknüpfte CVEs

4 weitere CVEs anzeigen
IDCVE-2026-68494