The vulnerability lies in Jackson’s non‑blocking parser handling integer digits for streamed JSON. When parsing a number that never ends with a terminator, the parser never calls the validator that enforces the configured maxNumberLength setting. Each incoming chunk expands the internal text buffer, which is only bounded by maxStringLength (20 MiB by default) instead of the intended 1 000‑digit limit. Consequently, an attacker can supply a sequence of small chunks that never terminates the number, causing the parser’s buffer to grow up to the maxStringLength limit, consuming heap memory at a rate that can exhaust the JVM with a single connection. No special privileges or user interaction are required, making the attack trivial through a simple stream of JSON data.

Versions of FasterXML jackson-core from 2.15.0 through 2.18.7, 2.19.0 through 2.21.3, and the 3.x series up through 3.1.3 are affected. Earlier releases prior to 2.15.0 are immune because the maxNumberLength constraint did not exist. This flaw is relevant to reactive frameworks that feed data into the async parser incrementally, such as Spring WebFlux/Reactor, Quarkus, Helidon, and Vert.x, but not to synchronous parsers or the async parser when processing complete inputs.

The flaw presents a high‑severity, low‑extrinsic‑requirement vulnerability (CVSS 8.7, no EPSS data). Attackers can induce denial of service on vulnerable applications simply by streaming large or maliciously crafted JSON numbers to exposed endpoints. The attack path is straightforward: send data in small chunks without terminating the number, exhausting the JVM heap. The flaw is not listed in CISA KEV. Lacking any enforcement of maxNumberLength, any application that relies on this setting for safety is exposed. The exploit is likely to succeed against any application using the affected versions of jackson-core in a reactive or streaming context.