Исправление, выпущенное в jackson-core 2.18.6 и 2.21.1 для CVE-2026-18401 (GHSA-72hv-8253-57qq, обход ограничения длины числа в неблокирующем анализаторе), является неполным. Эта запись охватывает оставшийся обход. Предыдущее исправление подключило validateIntegerLength() к новому помощнику _setIntLength() и вызывало его всякий раз, когда определяется целая часть числа: прибывает байт терминатора, . или e/E виден, или ввод заканчивается внутри полностью буферизованного значения.
Он не был вызван на пути, соответствующем злоумышленнику, где анализатору не хватает входных данных, хотя он все еще находится в второстепенном состоянии MINOR_NUMBER_INTEGER_DIGITS, и возвращает NOT_AVAILABLE вызывающему объекту. В результате злоумышленник, который передает JSON в неблокирующий анализатор множеством небольших фрагментов, даже не отправляя байт терминатора, сохраняет анализатор внутри MINOR_NUMBER_INTEGER_DIGITS на неопределенный срок. _textBuffer.expandCurrentSegment() увеличивает аккумулятор на каждом фрагменте, а validateIntegerLength() никогда не вызывается. Аккумулятор ограничен только maxStringLength (20 МБ по умолчанию), а не maxNumberLength (1000 по умолчанию), что примерно в 20 000 раз превышает документированный предел.
Поскольку символьные значения Java занимают два байта, одно соединение может занять примерно 40 МБ кучи, прежде чем валидатор окончательно сработает после завершения обработки значения. Эквивалентный код дробного пути верен: _finishFloatFraction() вызывает _setFractLength() перед возвратом NOT_AVAILABLE. Отсутствующий вызов влияет на целочисленные пути в _startPositiveNumber(), _startNegativeNumber() и _finishNumberIntegralPart() в NonBlockingUtf8JsonParserBase.
Влияние: реактивные платформы, такие как Spring WebFlux/Reactor, Quarkus, Helidon и Vert.x, передают входящие байты HTTP или gRPC асинхронному анализатору по мере их поступления, что как раз и является необходимой формой фрагментированной подачи. Операторы, которые устанавливают StreamReadConstraints.maxNumberLength, ожидая, что он будет ограничивать память на числовое значение, не получают такой гарантии; Память накапливается для каждого параллельного соединения, а параллелизм, контролируемый злоумышленником, может исчерпать кучу JVM. Синхронные анализаторы (UTF8StreamJsonParser, ReaderBasedJsonParser) и асинхронный анализатор, работающий с полным вводом, не затрагиваются.
Для эксплуатации требуется только возможность потоковой передачи данных в конечную точку синтаксического анализа; никаких привилегий или взаимодействия с пользователем не требуется. Эта проблема затрагивает com.fasterxml.jackson.core:jackson-core версий 2.15.0–2.18.7, 2.19.0–2.21.3 и 2.22.0–2.22.0, а также Tools.jackson.core:jackson-core версий 3.0.0–3.1.3 и 3.2.0–3.2.0. Версии до 2.15.0 не затрагиваются, поскольку StreamReadConstraints, определяющий параметр maxNumberLength, впервые был представлен в jackson-core 2.15.0, поэтому такого ограничения не существует, чтобы его можно было обойти в более ранних выпусках.
Обратите внимание, что в GHSA-r7wm-3cxj-wff9 указан затронутый диапазон 2.x без нижней границы.
Показать оригинальное описание (EN)
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).
Характеристики атаки
Последствия
Строка CVSS v4.0