jackson-dataformat-protobuf EUVD-2026-111531

Exploitation requires that the application parse attacker-controlled protobuf input using an affected jackson-dataformat-protobuf release (2.21.6-2.21.7, 2.22.0-2.22.3, 3.1.6-3.1.7, or 3.2.2-3.2.3) with a schema that contains a string-keyed map (map<string, V>); the vulnerable _readStringKey() path only executes for such map entries. No special parser configuration, no databind layer, and no user interaction are needed - a single 8-byte streaming-parser message triggers it, and configured StreamReadConstraints (maxStringLength/maxNameLength/maxDocumentLength/maxNestingDepth) do not prevent the failure. Limiting factors that reduce real-world exposure: versions 2.18-2.20, 3.0, 3.1.0-3.1.5 and 3.2.0-3.2.1 do not contain _readStringKey() and are not affected; the deployed schema must use a string-keyed map; and whether the triggering message can be sent by an unauthenticated remote attacker depends on how the hosting application exposes and authenticates its parsing endpoint. Impact is amplified on JVMs run with -XX:+ExitOnOutOfMemoryError, where the error terminates the process (observed exit code 3) rather than being recoverable.

All severity signals converge on a single, well-characterized denial-of-service issue rather than a code-execution threat. The supplied CVSS 3.1 vector (7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) scores only availability impact (A:H) with no confidentiality or integrity effect, which matches the described mechanism: an integer overflow in ProtobufParser._readStringKey() that defeats the signed (_inputPtr + len) <= _inputEnd bounds check and drives an oversized TextBuffer/Arrays.copyOf allocation, producing OutOfMemoryError from an 8-byte payload. The GHSA advisory documents a complete proof of concept (exact payload 0A 06 0A FF FF FF FF 07, reproduction procedure, and confirmed runtime reproduction in 2.21.6, 2.22.3 and 3.2.3), so exploitability is well established and effectively automatable via a single reproducible message. No EPSS score was provided in the input, and the CVE is not listed in CISA KEV, so there is no public evidence of active exploitation - this is a prompt-patch issue, not an in-the-wild emergency, consistent with the vuln.today 'this_week' decision label. The real priority is driven by three multipliers rather than the raw score: StreamReadConstraints (maxStringLength/maxNameLength/maxDocumentLength/maxNestingDepth) do NOT mitigate it; the 2.x branches were left unguarded after the related CVE-2026-104016/104017 fix touched only 3.x call sites; and hosts running -XX:+ExitOnOutOfMemoryError see full JVM termination (exit code 3), not just a caught parse error. The limiting factor that keeps this below a universal crisis is that it only applies where an application parses attacker-controlled protobuf with a schema containing a map<string, V> field in an affected version range.

An attacker sends a single 8-byte malformed protobuf message to any endpoint that deserializes attacker-controlled protobuf using an affected jackson-dataformat-protobuf version with a string-keyed map field; the declared key length of 0x7FFFFFFF overflows the bounds check and forces a near-2GB buffer allocation, throwing OutOfMemoryError. A documented proof of concept (payload and reproduction steps) exists in the vendor GHSA advisory, with runtime reproduction confirmed in 2.21.6, 2.22.3 and 3.2.3. Because AV:N/AC:L applies, the message can be delivered remotely with low complexity, and on JVMs started with -XX:+ExitOnOutOfMemoryError it kills the process outright, enabling repeatable service disruption on resubmission.