GHSA-R7WM-3CXJ-WFF9: StreamReadConstraints Bypass in jackson-core Async Parser

The library jackson-core contains a resource consumption vulnerability in its asynchronous, non-blocking parsing implementation. This flaw allows an unauthenticated remote attacker to cause an application-level Denial of Service by bypassing the primary defense mechanism against numeric overflow attacks.

The affected component is NonBlockingUtf8JsonParserBase, which is responsible for parsing JSON payloads asynchronously without blocking execution threads. This parser is commonly used in reactive frameworks such as Spring WebFlux, Vert.x, and Netty. The attack surface is exposed via any reactive endpoint that parses untrusted user JSON inputs using Jackson's asynchronous parsing capabilities.

The vulnerability represents a validation bypass of StreamReadConstraints.maxNumberLength, which restricts the length of numeric values to a default of 1,000 characters. Because the asynchronous parser fails to validate intermediate state lengths during chunk suspensions, the internal text buffer accumulates data up to the maxStringLength threshold. This leads to excessive heap memory allocation and garbage collection thrashing under concurrent load.

To prevent memory exhaustion, Jackson-core implements StreamReadConstraints which bounds the maximum length of various incoming tokens. When parsing synchronous streams, Jackson validates numeric lengths using the resetInt or resetFloat methods. These methods check constraints against the configured maxNumberLength limit before expanding internal memory structures.

In the original vulnerability GHSA-72hv-8253-57qq, the non-blocking parser bypassed standard validation by completing tokens via a direct call to _valueComplete. The maintainers attempted to patch this by routing state modifications through validation helpers: _setIntLength, _setFractLength, and _setExpLength. These helpers throw a StreamConstraintsException if the accumulated length exceeds the allowed threshold.

The vulnerability GHSA-R7WM-3CXJ-WFF9 arises because the helper validations are only invoked when a number token is complete. In non-blocking parsing, if a data chunk terminates without a numeric delimiter, the parser enters a suspended state. Specifically, when handling MINOR_NUMBER_INTEGER_DIGITS at the end of a buffer, the parser calls _textBuffer.setCurrentLength(outPtr) and yields JsonToken.NOT_AVAILABLE without invoking _setIntLength.

This omission allows an attacker to bypass constraints by transmitting a continuous stream of digits split into multiple small chunks. The parser saves its state, updates the buffer length, and returns to wait for more data without verifying the total accumulated length. The internal character buffer _textBuffer continually expands up to the default string constraint of 20 MiB before any exception is thrown.

The patch in commit 4cdd529749da396cc7edf6d4a2aad41d47902641 addresses the vulnerability by ensuring that constraint validation occurs during parser suspension states. Prior to this patch, when a buffer boundary was hit, the parser returned NOT_AVAILABLE without validating the accumulated digits.

Below is a comparison of the vulnerable code path versus the patched implementation within NonBlockingUtf8JsonParserBase.java.

// VULNERABLE CODE PATH
if (++_inputPtr >= _inputEnd) {
    _minorState = MINOR_NUMBER_INTEGER_DIGITS;
    _textBuffer.setCurrentLength(outPtr);
    // Missing: No validation check is conducted on outPtr before yielding
    return _updateTokenToNA();
}

The patch introduces the necessary validation calls using _setIntLength before the parser returns to a suspended state. The parameter is adjusted based on whether the number is negative or positive, ensuring precise character length counts are evaluated.

// PATCHED CODE PATH (Commit 4cdd529749da396cc7edf6d4a2aad41d47902641)
if (++_inputPtr >= _inputEnd) {
    _minorState = MINOR_NUMBER_INTEGER_DIGITS;
    _textBuffer.setCurrentLength(outPtr);
    // [core#1556]: validate accumulated integer length so far before yielding
    // NOT_AVAILABLE; otherwise a stream of digit-only chunks can grow the buffer
    _setIntLength(outPtr); 
    return _updateTokenToNA();
}

By invoking _setIntLength(outPtr) at each suspension point, the parser asserts that the accumulated digit count remains within the configured maxNumberLength boundary. If the limit is exceeded during an intermediate chunk state, a StreamConstraintsException is immediately thrown, terminating the connection and freeing the associated resources.

Exploitation of GHSA-R7WM-3CXJ-WFF9 requires an unauthenticated network path to an endpoint that processes asynchronous JSON payloads. The target application must be configured to utilize Jackson's non-blocking parser. This is typical in reactive microservice architectures utilizing the Spring WebFlux framework.

The attack is executed by initiating an HTTP POST request and streaming the JSON payload slowly over multiple TCP segments or HTTP chunks. The body starts with a standard key-value layout such as {\"v\": followed by an unbroken sequence of numerical digits without any trailing delimiter.

Because the parser suspends state waiting for additional input, it does not validate the total numeric length until a terminating character is found. An attacker can drip small packets containing only digits, inflating memory usage for each active request. Under concurrent execution, sending many such slow-drip streams simultaneously causes rapid heap memory consumption, resulting in high CPU usage due to garbage collection loops and eventual JVM failure.

The concrete security impact of this vulnerability is a complete application-level Denial of Service. While the flaw does not facilitate arbitrary code execution or unauthorized access to sensitive data, it permits unauthenticated users to crash target services with minimal bandwidth overhead.

The parent vulnerability, GHSA-72hv-8253-57qq, carries a CVSS v4.0 score of 5.3 (Medium). This rating reflects a localized availability impact. However, because GHSA-R7WM-3CXJ-WFF9 represents a complete validation bypass of the primary defensive boundary, the practical risk is elevated for high-throughput reactive microservices.

A successful attack forces the JVM to allocate large buffers (up to 20 MiB per stream) that cannot be garbage collected while the connection remains active. When multiple requests are processed in parallel, the combined memory footprint triggers an OutOfMemoryError. This results in service unavailability, termination of containerized application pods, and downstream operational disruption.

The primary remediation strategy is upgrading the jackson-core dependency to a patched version. For applications operating on the 2.19.x release branch, upgrade to version 2.19.2 or later. For applications utilizing the 2.20.x or 2.21.x branches, upgrade to 2.21.1 or later. If running the 3.x.x pre-release branch, upgrade to 3.1.0.

In environments where immediate dependency upgrades are not feasible, temporary mitigation can be achieved by decreasing the maxStringLength parameter within StreamReadConstraints. Because the unchecked numeric accumulation is capped by the maximum allowed string length, lowering this limit from its default of 20 MiB restricts the worst-case heap allocation per connection.

// Example mitigation by configuring custom StreamReadConstraints
StreamReadConstraints constraints = StreamReadConstraints.builder()
    .maxNumberLength(1000)
    .maxStringLength(50000) // Restricted to limit maximum memory consumption
    .build();
 
JsonFactory factory = JsonFactory.builder()
    .streamReadConstraints(constraints)
    .build();

Additionally, deploying web application firewalls (WAF) or reverse proxies (such as NGINX or HAProxy) configured with strict read timeouts and minimum incoming data rate limits helps block slow-drip attacks. Enforcing a minimum upload rate ensures that client connections streaming data in excessively small chunks are prematurely closed, mitigating resource exhaustion before the payload reaches the application parser.