# CVE-2026-45799 ## Maintainer summary Wire's protobuf group-skipping logic did not reject negative lengths before skipping a length-delimited field inside a group. A crafted protobuf payload could cause Wire to throw an unchecked runtime exception during decoding instead of the documented `IOException` / `ProtocolException` failure path. This can crash services that decode untrusted protobuf payloads and only handle Wire's documented checked decoding failures. ## Affected artifacts ### `com.squareup.wire:wire-runtime` Affected versions: vulnerable releases before `6.3.0`. Patched versions: `6.3.0` and later. Users should upgrade to `com.squareup.wire:wire-runtime:6.3.0` or later. ### `com.squareup.wire:wire-runtime-jvm` Affected versions: vulnerable releases before `6.3.0`. Patched versions: `6.3.0` and later. Users should upgrade to `com.squareup.wire:wire-runtime:6.3.0` or later. ### Wire 7 alpha releases The fix has been merged to `master` and will be included in the next Wire 7 alpha release. Until that release is available, Wire 7 alpha users should avoid decoding untrusted protobuf payloads with affected alpha versions or build from a commit containing the fix. ## Fix The issue is fixed in Wire `6.3.0`. The fix rejects negative lengths while skipping groups and throws `ProtocolException` instead of allowing the reader to move to an invalid position and later throw an unchecked runtime exception. ## Credit Reported by @TrekLaps. ## Technical details The following technical details are based on the original report, updated by the maintainers to reflect the assigned CVE, the supported fixed artifact, and the discontinued status of `com.squareup.wire:wire-runtime-jvm`. `ByteArrayProtoReader32.skipGroup()` in `wire-runtime` did not validate that a `LENGTH_DELIMITED` field's length is non-negative before calling `skip()`. A crafted protobuf varint encodes `-128` as a signed `Int`. When `skip(-128)` runs, the internal position counter underflows to an invalid negative position. The next `readByte()` accesses the source with that negative position, throwing `ArrayIndexOutOfBoundsException`, a `RuntimeException` that escapes Wire's documented `IOException` boundary and can crash the request handler. `ProtoAdapter.decode(byte[])` is declared to throw `IOException`. Callers following the documented API may catch only `IOException`, so unchecked runtime exceptions from malformed input can escape the expected error boundary. The originally confirmed vulnerable legacy versions include `5.3.1` and `5.3.3` for the discontinued `com.squareup.wire:wire-runtime-jvm` coordinate. The supported replacement coordinate is `com.squareup.wire:wire-runtime`, fixed in version `6.3.0`. ## Root cause In the originally reported vulnerable code path, `ByteArrayProtoReader32.skipGroup()` read the length as a signed `Int` and used it without validating that it was non-negative: ```kotlin STATE_LENGTH_DELIMITED -> { val length = internalReadVarint32() // returns signed Int and can be negative skip(length) // no negative check } ``` The internal `skip()` implementation then accepted the negative count because the computed position was not greater than the limit: ```kotlin private fun skip(byteCount: Int) { val newPos = pos + byteCount // for example, 7 + (-128) = -121 if (newPos > limit) throw EOFException() pos = newPos // pos = -121 } ``` The next read could then index the source with the invalid negative position: ```kotlin private fun readByte(): Byte { if (pos == limit) throw EOFException() return source[pos++] // source[-121] throws ArrayIndexOutOfBoundsException } ``` Wire already rejected negative lengths in normal length-delimited field decoding. The same validation was missing from group-skipping code. The fix adds this validation when skipping groups: ```kotlin STATE_LENGTH_DELIMITED -> { val length = internalReadVarint32() if (length < 0) throw ProtocolException("Negative length: $length...") skip(length) } ``` The fix was applied to both `ByteArrayProtoReader32.skipGroup()` and `ProtoReader.skipGroup()`. ## Reproduction The following reproduction was provided for vulnerable legacy `wire-runtime-jvm` releases such as `5.3.1` and `5.3.3`: ```bash curl -sL https://repo1.maven.org/maven2/com/squareup/wire/wire-runtime-jvm/5.3.3/wire-runtime-jvm-5.3.3.jar -o wire.jar curl -sL https://repo1.maven.org/maven2/com/squareup/okio/okio-jvm/3.9.1/okio-jvm-3.9.1.jar -o okio.jar curl -sL https://repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib/2.1.0/kotlin-stdlib-2.1.0.jar -o stdlib.jar ``` ```java // WirePoc.java import com.squareup.wire.AnyMessage; public class WirePoc { public static void main(String[] args) throws Exception { byte[] payload = new byte[] { (byte) 0x9B, 0x06, // field 99, START_GROUP 0x0A,

AI Analysis