CVE-2026-104016 in jackson-dataformat-protobuf
Summary
by MITRE • 10/28/2026
ProtobufParser parses length-prefixed protobuf string and bytes fields by checking (_inputPtr + len) <= _inputEnd and then, on the fast path, calling _finishShortText(len). Both use 32-bit signed integer arithmetic. When an attacker supplies a varint decoding to a length near Integer.MAX_VALUE, _inputPtr + len overflows to a negative value, the bounds check passes, and _finishShortText(len) reaches TextBuffer.expandCurrentSegment(len), which performs Arrays.copyOf with no cap and throws OutOfMemoryError: Requested array size exceeds VM limit.
The JVM refuses arrays larger than Integer.MAX_VALUE - 8 before consulting available heap, so -Xmx tuning does not mitigate the issue. StreamReadConstraints.maxStringLength and maxDocumentLength do not gate this path: a 33-byte payload is far below any document-length cap and the string-length check does not fire before the allocation. This was confirmed empirically against shipping artifacts with maxStringLength, maxDocumentLength and maxNestingDepth all configured.
A February 2026 hardening commit added the equivalent overflow guard to the packed-array-length and message-length paths but left the string-length call sites unguarded. No privileges or user interaction beyond the ability to submit data for parsing are required.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability in question represents a critical integer overflow flaw within the ProtobufParser component, specifically affecting the handling of length-prefixed protobuf string and bytes fields. The core technical failure stems from the use of 32-bit signed integer arithmetic when calculating buffer boundaries. During parsing, the system checks if the sum of the current input pointer position (_inputPtr) and the declared field length (len) is less than or equal to the end of the input stream (_inputEnd). This calculation relies on standard Java int operations, which wrap around upon overflow. When an attacker crafts a payload containing a varint-encoded length value near Integer.MAX_VALUE, specifically 2147483647 or similar high values that cause the addition _inputPtr + len to exceed the maximum positive integer limit, the result wraps into negative territory due to two's complement arithmetic rules. Consequently, this negative sum passes the bounds check because it is technically less than the positive end pointer value, creating a false sense of security regarding memory safety within the parser logic.
Following the failed boundary validation on the fast path, the execution proceeds to call _finishShortText(len), which subsequently invokes TextBuffer.expandCurrentSegment(len). This method attempts to allocate a new array segment using Arrays.copyOf without applying any upper cap or overflow protection for the requested size. The Java Virtual Machine imposes a hard limit on array sizes, refusing allocations larger than Integer.MAX_VALUE minus eight bytes before even consulting available heap space. Because the length parameter derived from the malicious varint is effectively treated as a massive positive integer after the initial arithmetic error, the JVM attempts to allocate an impossibly large block of memory. This results in an OutOfMemoryError: Requested array size exceeds VM limit exception. Unlike typical denial-of-service scenarios where heap exhaustion occurs gradually through many small allocations, this flaw triggers an immediate and catastrophic failure due to a single massive allocation request that violates fundamental JVM constraints.
The operational impact of this vulnerability is severe, primarily manifesting as a Denial of Service against any service relying on the affected ProtobufParser implementation. Since no privileges or user interaction beyond the ability to submit data for parsing are required, an attacker can remotely trigger this condition by sending specially crafted protobuf messages. The issue persists regardless of standard JVM tuning parameters such as -Xmx because the failure occurs at the array allocation level before heap availability is even considered. Furthermore, existing security controls like StreamReadConstraints.maxStringLength and maxDocumentLength fail to mitigate this specific attack vector. These constraints are not applied early enough in the parsing pipeline; a malicious payload with a length field near Integer.MAX_VALUE but containing only a small amount of actual data (e.g., 33 bytes) bypasses these checks entirely because the string-length validation does not fire before the memory allocation attempt. This gap allows attackers to exploit the parser even when strict document and nesting depth limits are configured, as confirmed by empirical testing against shipping artifacts with comprehensive security constraints enabled.
This flaw highlights a significant oversight in defensive coding practices regarding integer overflow protection during arithmetic operations involving user-controlled lengths. While a hardening commit implemented in February 2026 successfully added equivalent overflow guards to packed-array-length and message-length paths, it inadvertently left the string-length call sites unguarded. This inconsistency creates an exploitable gap that attackers can leverage to disrupt service availability. To address this vulnerability, developers must implement explicit checks for integer overflow before performing arithmetic operations on length fields derived from external input. Specifically, code should verify that _inputPtr + len does not wrap around by checking if len is greater than Integer.MAX_VALUE - _inputPtr prior to the bounds check. Additionally, integrating these safeguards into StreamReadConstraints or equivalent validation layers would ensure that all parsing paths are protected against malformed length values. Aligning this fix with industry standards such as CWE-190 (Integer Overflow or Wraparound) and ATT&CK techniques related to resource exhaustion will help prevent similar vulnerabilities in future implementations of protocol parsers.