GHSA-c2rq-mcfv-jw29: jackson-dataformat-protobuf: signed integer overflow in string-length paths allows unbounded array allocation and OutOfMemoryError

Q: Which deployments are realistically exposed?

Applications that use ProtobufParser to process attacker-controlled protobuf input containing length-prefixed string or bytes fields are exposed. Exploitation requires no privileges or user interaction.

Q: What does an attacker need to send?

The attacker needs a crafted protobuf payload whose varint length decodes to a value near Integer.MAX_VALUE. The described proof payload is only 33 bytes, so large request bodies are not required.

Q: Do configured Jackson stream-read limits prevent exploitation?

No. StreamReadConstraints.maxStringLength and maxDocumentLength do not gate this allocation path, and the issue was confirmed with those limits and maxNestingDepth configured.

Q: Can increasing or reducing the JVM heap limit mitigate the issue?

No. The JVM rejects arrays larger than Integer.MAX_VALUE minus 8 before available heap is considered, so -Xmx tuning does not prevent the resulting OutOfMemoryError.

Q: How might an attempted exploit appear operationally?

A vulnerable parser can throw an OutOfMemoryError stating that the requested array size exceeds the VM limit. This occurs when the crafted length bypasses the overflow-prone bounds check and reaches the array expansion path.

Published Oct 27, 2026

Updated

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.MAXVALUE, 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.MAXVALUE - 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.

Event History

Oct 27, 2026

CVE Published

via OSV·11:52 PM

Data Sourced

via OSV·11:52 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Which deployments are realistically exposed?

Applications that use ProtobufParser to process attacker-controlled protobuf input containing length-prefixed string or bytes fields are exposed. Exploitation requires no privileges or user interaction.

What does an attacker need to send?

The attacker needs a crafted protobuf payload whose varint length decodes to a value near Integer.MAX_VALUE. The described proof payload is only 33 bytes, so large request bodies are not required.

Do configured Jackson stream-read limits prevent exploitation?

No. StreamReadConstraints.maxStringLength and maxDocumentLength do not gate this allocation path, and the issue was confirmed with those limits and maxNestingDepth configured.

Can increasing or reducing the JVM heap limit mitigate the issue?

No. The JVM rejects arrays larger than Integer.MAX_VALUE minus 8 before available heap is considered, so -Xmx tuning does not prevent the resulting OutOfMemoryError.

How might an attempted exploit appear operationally?

A vulnerable parser can throw an OutOfMemoryError stating that the requested array size exceeds the VM limit. This occurs when the crafted length bypasses the overflow-prone bounds check and reaches the array expansion path.

GHSA-c2rq-mcfv-jw29: jackson-dataformat-protobuf: signed integer overflow in string-length paths allows unbounded array allocation and OutOfMemoryError

Event History

Frequently Asked Questions

Which deployments are realistically exposed?

What does an attacker need to send?

Do configured Jackson stream-read limits prevent exploitation?

Can increasing or reducing the JVM heap limit mitigate the issue?

How might an attempted exploit appear operationally?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are realistically exposed?

What does an attacker need to send?

Do configured Jackson stream-read limits prevent exploitation?

Can increasing or reducing the JVM heap limit mitigate the issue?

How might an attempted exploit appear operationally?