jackson-dataformat-protobuf CVE-2026-104016

The target application must accept untrusted protobuf input and parse it via jackson-dataformat-protobuf (ProtobufMapper/ProtobufParser) using a schema that contains a string or bytes field the attacker can influence - the condition is specifically a length-prefixed string/bytes field whose varint length is attacker-controlled. No authentication or user interaction is required (PR:N/UI:N), and default ProtobufMapper configuration is vulnerable. Critically, the usual limiting factors do NOT apply: StreamReadConstraints.maxStringLength, maxDocumentLength, and maxNestingDepth are all bypassed (confirmed empirically), and JVM -Xmx tuning does not help because the array-size-limit check fires before heap consultation. The real limiting factor is scope of exposure: only services that actually deserialize attacker-reachable protobuf with string/bytes fields are affected, and the impact is confined to availability (process OOM/crash) - no confidentiality or integrity loss.

This is a genuine but bounded priority. The CVSS 7.5 vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) is credible: a remote actor with no privileges or interaction can crash a process with a 33-byte payload, and the impact is strictly availability (C:N/I:N) - no data exposure or code execution. The decision label is 'this_week' (not act_now/emergency). KEV status is NO - this is not on CISA KEV, so there is no confirmed active exploitation. No EPSS score was provided, so statistical exploitation probability cannot be weighed here. A full working proof-of-concept is published in the GHSA advisory and was empirically confirmed by the reporter to trigger OutOfMemoryError against shipping 2.21.7 and 3.1.7 Maven Central jars, so exploitability is proven even without KEV/EPSS signals. The signals are internally consistent - network-reachable, trivial complexity, DoS-only - and the standout aggravator is that the two documented defenses (StreamReadConstraints maxStringLength/maxDocumentLength and JVM -Xmx heap tuning) do NOT mitigate this path, which raises its real-world weight above a typical availability bug. Net: prioritize patching for any service parsing untrusted protobuf, but it remains a denial-of-service issue, not a confidentiality/integrity compromise.

An attacker submits a tiny (~33-byte) protobuf payload to a service that parses untrusted protobuf via jackson-dataformat-protobuf (e.g. a gRPC-to-JSON gateway or Kafka consumer using ProtobufMapper), encoding a string/bytes field whose varint length decodes to near Integer.MAX_VALUE. The signed-int bounds check overflows negative and passes, so the parser attempts a multi-gigabyte array allocation and the JVM throws OutOfMemoryError, crashing or destabilizing the service. Given AV:N/AC:L/PR:N/UI:N and a published, empirically confirmed PoC in the GHSA advisory, this requires no authentication, user interaction, or special timing.