Summary An integer overflow in "ProtobufParser._readStringKey()" allows a malformed protobuf message containing a "map<string, V>" field to trigger "OutOfMemoryError" with an 8-byte payload. The parser adds an attacker-controlled key length to "_inputPtr" using signed integer arithmetic. A declared length of "Integer.MAX_VALUE" causes the addition to overflow, incorrectly passing the buffer-availability check and triggering an oversized text-buffer allocation before any key data is consumed. Runtime reproduction confirms the issue in released versions 2.21.6, 2.22.3. Configured "StreamReadConstraints" do not prevent the failure. With "-XX:+ExitOnOutOfMemoryError", the reproduction terminates the JVM with exit code 3. The related CVE-2026-104016/104017 remediation addresses this map-key call site on the 3.x branches, but the corresponding 2.x branches remain unguarded as of 2026-10-06. The report therefore identifies a missed 2.x remediation site, including branches targeting 2.21.8 and 2.22.4. ### Details ### Vulnerable code "ProtobufParser._readStringKey()" reads the length prefix of a protobuf map entry’s string key into an attacker-controlled "int len", then checks: "java if ((_inputPtr + len) <= _inputEnd) { return _finishShortText(len); } " For values near "Integer.MAX_VALUE", "_inputPtr + len" overflows to a negative value. The condition consequently passes even when the input contains no key data. The parser enters "_finishShortText(len)", which eagerly expands the text buffer using the declared length: "text _finishShortText(len) → TextBuffer.expandCurrentSegment(len) → Arrays.copyOf(...) → OutOfMemoryError: Requested array size exceeds VM limit " ### Confirmed locations - Version 2.22.3: "_readStringKey()", line 1351. - Version 3.2.3: "_readStringKey()", line 1310. The reproduced 2.22.3 call path is: "text ProtobufParser.nextToken:740 → _openMapEntry:1176 → _readMapKeyValue:1288 → _readStringKey:1351 → _finishShortText:2325 → TextBuffer.expandCurrentSegment:1113 → Arrays.copyOf → OutOfMemoryError " ### Affected versions and branch status Runtime reproduction confirms released versions 2.21.6, 2.22.3, and 3.2.3. Source/bytecode inspection identifies the vulnerable path in 2.21.6–2.21.7, 2.22.0–2.22.3, and released 3.x versions with map support, including 3.2.0–3.2.3. The inspected 2.18–2.20 lines do not contain this map-key path. Branch inspection on 2026-10-06 showed: | Branch | Map-key check | Status | |---|---|---| | "2.21", "2.22", "2.x" | "(_inputPtr + len) <= _inputEnd" | Vulnerable | | "3.1", "3.2", "3.x" | "len <= (_inputEnd - _inputPtr)" with name-length validation | Fixed in branch HEAD; unreleased | | "2.18", "2.19", "2.20" | "_readStringKey()" absent | Not affected by this vector | ### Relationship to the existing remediation This is the same integer-overflow pattern addressed by "PR #817" (https://github.com/FasterXML/jackson-dataformats-binary/pull/817), associated with CVE-2026-104016/104017. The map-key correction in "commit a4d05bd" (https://github.com/FasterXML/jackson-dataformats-binary/commit/a4d05bd) describes "_readStringKey()" as “3.x only.” ### Proof of concept ### Preconditions Use "jackson-dataformat-protobuf" with a schema containing a string-keyed map: "proto syntax = "proto3"; message T { map<string, int32> m = 1; } " The reproduction uses the streaming parser and "nextToken()"; databind is not required. ### Payload "text 0A 06 0A FF FF FF FF 07 " Interpretation: "text 0A Field 1: map entry, wire type 2 06 Map-entry length: 6 bytes 0A Key field 1: string, wire type 2 FF FF FF FF 07 Declared key length: 0x7FFFFFFF " The complete message is 8 bytes and contains no key data. ### Reproduction procedure 1. Run "poc/MapKeyOOM.java" against the released 2.22.3 artifacts. 2. Parse the benign map entry "{hi:7}" to confirm normal parser operation. 3. Parse the malicious 8-byte message using the same schema and repeated "nextToken()" calls. 4. Repeat with the configured constraints described below. 5. Repeat with "-XX:+ExitOnOutOfMemoryError" to demonstrate JVM termination. 6. Repeat against 2.21.6 and run "poc/MapKeyOOM3.java" against 3.2.3. Commands for the supplied 2.x reproduction source: "bash cd poc/ curl -fSsO https://repo1.maven.org/maven2/com/fasterxml/jackson/dataformat/jackson-dataformat-protobuf/2.22.3/jackson-dataformat-protobuf-2.22.3.jar curl -fSsO https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.22.3/jackson-core-2.22.3.jar javac -cp 'jackson-dataformat-protobuf-2.22.3.jar:jackson-core-2.22.3.jar' MapKeyOOM.java java -Xmx128m \ -cp '.:jackson-dataformat-protobuf-2.22.3.jar:jackson-core-2.22.3.jar' \ MapKeyOOM java -Xmx128m \ -cp '.:jackson-dataformat-protobuf-2.22.3.jar:jackson-core-2.22.3.jar' \ MapKeyOOM constrained java -Xmx128m -XX:+ExitOnOutOfMemoryError \ -cp '.:jackson-dataformat-protobuf-2.22.3.jar:jackson-core-2.22.3.jar' \ MapKeyOOM " The constrained run sets: "text maxStringLength=1000 maxNameLength=1000 maxDocumentLength=1000 maxNestingDepth=5 " ### Observed result The benign message parses successfully. The malicious message produces: "text Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit at com.fasterxml.jackson.core.util.TextBuffer.expandCurrentSegment(TextBuffer.java:1113) at ...ProtobufParser._finishShortText(ProtobufParser.java:2325) at ...ProtobufParser._readStringKey(ProtobufParser.java:1351) " The constrained run produces the same failure. With "-XX:+ExitOnOutOfMemoryError": ```text Terminating due to java.lang.OutOfMemoryError: Requested array size exceeds VM ### Impact This vulnerability enables denial of service in applications that parse attacker-controlled protobuf messages using "jackson-dataformat-protobuf" and a schema containing a "map<string, V>" field. A single 8-byte malformed message triggers an allocation attempt based on "Integer.MAX_VALUE", resulting in "OutOfMemoryError". Applications configured with "-XX:+ExitOnOutOfMemoryError" terminate the JVM; the reproduction confirms exit code 3. Deployments configured to restart failed processes may experience repeated service disruption if malicious input is resubmitted. The parser failure requires no special parser configuration, user interaction, or databind operation. Authentication requirements depend on the application exposing the parsing endpoint. The proposed network severity applies where an unauthenticated remote attacker can submit messages to that endpoint. Configured "StreamReadConstraints" did not prevent the reproduced failure. Proposed severity: High — CVSS 3.1 7.5 Vector: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H" No confidentiality or integrity impact is demonstrated. Availability impact is supported by the parser OOM and JVM-termination evidence. The 2.x remediation gap is particularly relevant: as of 2026-10-06, the branches targeting the related CVE-fix releases 2.21.8 and 2.22.4 still retain this vulnerable call site.