GHSA-r7wm-3cxj-wff9 jackson-core: Async parser maxNumberLength bypass via chunked digit accumulation (incomplete fix for GHSA-72hv-8253-57qq)
SummaryThe fix released in jackson-core `2.18.6` and `2.21.1` for [GHSA-72hv-8253-57qq](https://github.com/FasterXML/jackson-core/security/advisories/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 versionsVerified 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`](https://github.com/FasterXML/jackson-core/blob/b0c428e6/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:Site 2 — `_finishNumberIntegralPart` lines 1691-1727:The pattern recurs at lines 1297, 1329, 1343, 1365, 1395, 1409, 1437, 1467, 1481, 1586, 1644, 1698 — every "ran out of input mid-integer" exit returns to the caller without validating the accumulator length.Compare with the fraction path that is correct`_finishFloatFraction` lines 1827-1838:ImpactReactive frameworks (Spring WebFlux / Reactor, Quarkus, Helidon, Vert.x JSON, anything wrapping `JsonFactory.createNonBlockingByteArrayParser()` or `createNonBlockingByteBufferParser()`) feed inbound HTTP/gRPC bytes to the async parser as they arrive. Operators who set `StreamReadConstraints.builder().maxNumberLength(N)` on the assumption that this caps memory per number value are not getting that guarantee in chunked-feed scenarios. The parser silently accumulates digits up to `maxStringLength` (20 MiB default) per concurrent connection. Multiply by attacker-controlled concurrency to OOM the JVM.The synchronous parsers (`UTF8StreamJsonParser`, `ReaderBasedJsonParser`) and the async parser on *complete* input are not affected — those paths go through `_setIntLength` or `ParserBase._reportTooLongIntegral` correctly.CWE-770 (Allocation of Resources Without Limits or Throttling), CVSS roughly the same as the parent advisory (Network / Low complexity / High availability impact). The parent advisory was scored CVSS 8.7 High.Proof of conceptStandalone PoC, no Maven required:Observed output against `jackson-core-2.18.6`:Observed output against `jackson-core-2.21.1`: identical.The 9.83 MB figure is purely a function of the loop bound (600 chunks * 16 KiB). The actual ceiling is `maxStringLength = 20 MiB`. With the strict policy declared as `maxNumberLength = 1000`, the parser permits **9830x** more allocation than the policy allows. With `maxStringLength` left at the default 20 MiB, an attacker can drive a single connection to 40 MiB of `char[]` heap (chars are 2 bytes each) before the validator finally fires on terminator/`endOfInput()`. Multiply by concurrent connections.End-to-end reproduction through real HTTPSupplements the standalone PoC with a running Spring Boot WebFlux server,
driving the same bug through the actual reactor-netty + Jackson2JsonDecoder
streaming-decode path that production reactive endpoints use.Setup:Spring Boot 3.3.5 starter-webflux (spring-webflux 6.1.14, reactor-netty 1.1.23)jackson-databind 2.17.2, jackson-core overridden:VULN run: `com.fasterxml.jackson.core:jackson-core:2.18.7` (latest published)PATCHED run: `2.18.8-SNAPSHOT` built from the fix branchJVM: OpenJDK 17.0.18Server `JsonFactory` configured with `StreamReadConstraints.builder().maxNumberLength(1000).build()`Endpoint under test exposes the `Flux<DataBuffer>` request body directly to
`Jackson2JsonDecoder.decode(Flux, ResolvableType, ...)` so the parser sees one
HTTP chunk per `feedInput` (the same pattern used for any
`@RequestBody Flux<...>` / streaming JSON decoder in WebFlux). A raw-socket
HTTP/1.1 chunked client streams `{"v":1` then 250 chunks of 200 digit bytes
each (50,000 digits total) at 20ms intervals, then writes the closing `}`.VULN — jackson-core 2.18.7:Server-side controller trace (250 DataBuffer arrivals elided):Server held all 50,000 digit characters in `_textBuffer` for 6.5 seconds with
`maxNumberLength=1000` declared. The validator never fires during streaming;
it only fires at value-completion when the closing `}` arrives.PATCHED — jackson-core 2.18.8-SNAPSHOT (fix branch):Server-side controller trace:Patched server raises `StreamConstraintsException` at 155ms after only 5
DataBuffers, exactly when the accumulated digit count crosses
`maxNumberLength=1000`. The connection is reset mid-stream rather than the
parser silently consuming the rest of the attacker's payload.Side-by-side:| Build | Chunks accepted before exception | Digits buffered | Time to detection |
|---|---|---|---|
| jackson-core 2.18.7 | 250 (full payload) | 50,000 (50x the configured limit) | 6,548ms — only at terminator |
| 2.18.8-SNAPSHOT (fix branch) | 5 | 1,001 | 155ms — moment threshold crossed |Note on the default `@RequestBody Mono<JsonNode>` path: that path cannot
distinguish the two builds because Spring's `decodeToMono` joins all
DataBuffers into one before parsing. The exploitable shape is the
streaming-decode path (`Flux<JsonNode>` / `@RequestBody Flux<...>` /
WebSocket / SSE / any direct `decoder.decode(Flux<DataBuffer>, ...)` call),
which is also what `Jackson2Tokenizer` uses for any streaming JSON
deserialization in WebFlux and Quarkus reactive REST.Suggested fixMirror the pattern already used in `_finishFloatFraction`. At every site that returns `_updateTokenToNA()` (or `JsonToken.NOT_AVAILABLE`) with `_minorState = MINOR_NUMBER_INTEGER_DIGITS`, call `_setIntLength(outPtr + negMod)` first. Concretely, the diff to `NonBlockingUtf8JsonParserBase.java` would be:Note: `_setIntLength` itself can't be used as-is because it also assigns `_intLength`, and `_intLength` must not be set until the integer is truly complete (subsequent fraction handling reads `_intLength`). The minimal fix is to call only the validator, as shown.Apply the same one-line insertion before each `return _updateTokenToNA();` that exits with `_minorState = MINOR_NUMBER_INTEGER_DIGITS`. The sites are listed above (12 lines total).Alternatively, a heavier refactor: also gate `_textBuffer.expandCurrentSegment()` calls inside the digit-accumulation loops on `outPtr < maxNumberLength` so that the validator fires at the moment the buffer would be enlarged past the limit, rather than waiting for the next chunk boundary. Either approach is sufficient.CreditReported by `tonghuaroot` (`tonghuaroot@gmail.com`). Variant hunt against the Feb 2026 fix for GHSA-72hv-8253-57qq.
CVSS v4.0 score: 8.7