CVE-2026-63126: Wire: Unauthenticated decoder crash via 32-bit length integer overflow in ByteArrayProtoReader32 (incomplete fix of CVE-2026-45799)

Wire’s protobuf decoders did not consistently validate attacker-controlled length-delimited sizes against the current reader bounds before computing cursor, limit, or pointer positions.

In the Kotlin runtime, ProtoAdapter.decode(ByteArray) and ProtoAdapter.decode(ByteString) use the ProtoReader32 fast path implemented by ByteArrayProtoReader32. In ByteArrayProtoReader32.internalNextLengthDelimited(), Wire read an untrusted varint length into an Int and rejected only negative values. A length such as 2147483647 is non-negative, so it passed that check, but pos + length overflowed the signed 32-bit cursor and produced a negative limit. The following if (limit > pushedLimit) guard did not catch this because the overflowed value was negative.

That invalid limit then reached string, bytes, skip, and scalar-reading paths as an invalid byte count or invalid range. Instead of failing as a checked decode error such as IOException, malformed input could throw unchecked runtime exceptions including IllegalArgumentException and ArrayIndexOutOfBoundsException. Applications commonly treat malformed protobuf input as an expected decode failure; unchecked runtime exceptions escaping that boundary can crash request handling or the process.

The original report is a sibling of the negative-length skipped-group bug fixed as CVE-2026-45799. It is not the same bug. The length in this advisory is positive, and the overflow occurs when setting a length-delimited message limit, not only when skipping a group.

While auditing for the same bug class, related boundary flaws were also found and fixed:

• Kotlin ProtoReader now validates logical message limits before varint, fixed32, fixed64, and skip operations. The originally reported byte-array overflow payload did not reproduce as the same signed overflow in ProtoReader, because that reader tracks positions as Long, but the streaming reader still needed consistent current-message-limit enforcement.
• Swift ReadBuffer.readVarint() read pointer.pointee before checking that one byte remained. A tag-only varint field could read past the end of the buffer.
• Swift ReadBuffer.verifyAdditional(count:) formed pointer.advanced(by: count) before proving the requested count fit within the remaining buffer, so pointer arithmetic ran before the bounds were established. (The distinct Swift negative-length skipGroup() crash is tracked separately as GHSA-86wm-r4c5-2rc9 / CVE-2026-61695; this advisory covers the positive/oversized-length boundary failures.)
• Swift nested-message decoding and packed-repeated decoding computed end pointers from untrusted lengths before validating that the bytes were present.
• Swift packed-repeated decoding reserved array capacity from an untrusted length before validating that the length existed in the current buffer.
• Swift size-delimited decoding converted an untrusted UInt64 varint size to Int without exactness or availability checks. On platforms where the value is not representable, this could trap.

The fix enforces a single invariant across the hardened readers: every decoded or skipped byte count must be non-negative and no larger than the remaining bytes in the current logical message limit before any cursor, pointer, limit, allocation, or slice is advanced.