Description

Wire provides gRPC and protocol buffers for Android, Kotlin, Swift, and Java. Prior to 6.4.5 and 7.0.0-alpha04, Wire protobuf readers do not consistently validate attacker-controlled lengths against the current logical message boundary before advancing cursors, pointers, limits, slices, or allocations. In Kotlin, ProtoAdapter.decode(ByteArray) and ProtoAdapter.decode(ByteString) use ByteArrayProtoReader32.internalNextLengthDelimited(), where a positive oversized length can wrap pos + length to a negative limit and escape the existing negative-length check. Related ProtoReader, ReadBuffer.readVarint(), ReadBuffer.verifyAdditional(count:), packed-repeated, nested-message, and ProtoDecoder.decodeSizeDelimited(_:from:) paths can cross logical boundaries, perform pointer arithmetic, reserve capacity, or convert an unrepresentable size before proving the requested bytes exist. An attacker who supplies malformed protobuf bytes can cause unchecked exceptions, traps, out-of-bounds behavior, or excessive allocation, resulting in denial of service without known confidentiality, integrity, or code-execution impact. This issue is fixed in versions 6.4.5 and 7.0.0-alpha04.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-16T19:17:24.013Z",
  "pubdate": "2026-09-16T19:17:24.013Z",
  "executiveSummary": "The Wire gRPC and protocol buffer library for Android, Kotlin, Swift, and Java contains a critical input validation vulnerability.\nThe flaw exists within the protobuf reader implementation, where attacker-controlled length fields are not consistently validated against logical message boundaries.\nAn unauthenticated attacker can supply malformed protobuf payloads to trigger out-of-bounds memory behavior, excessive resource allocation, or unhandled exceptions.\nThe primary impact of this vulnerability is a Denial of Service (DoS) resulting from system crashes or memory exhaustion.\nThere is currently no evidence of confidentiality, integrity, or arbitrary code execution impacts.\nAffected products include Wire versions prior to 6.4.5 and 7.0.0-alpha04.\nRisk management should prioritize updating the library, as the exploitation requirement is merely the ability to deliver a malformed protobuf message to an endpoint utilizing the affected reader functions.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper handling of length-delimited fields within Wire's protobuf decoding logic, specifically in Kotlin-based implementations such as ProtoAdapter.decode(ByteArray) and ProtoAdapter.decode(ByteString).\nThe vulnerability stems from the use of ByteArrayProtoReader32.internalNextLengthDelimited(), which fails to perform robust boundary checks when processing incoming data lengths. Specifically, the implementation allows a positive, oversized length integer to trigger an integer overflow when calculating the buffer position (pos + length). This overflow can result in a negative value, which bypasses existing sanity checks designed to catch invalid message lengths.\nThe issue propagates across several internal components, including ProtoReader, ReadBuffer.readVarint(), and ReadBuffer.verifyAdditional(count:). In these paths, the reader fails to prove that the requested number of bytes actually exists within the logical message boundary before performing pointer arithmetic, reserving memory capacity, or advancing the internal cursor.\nThe attack flow begins when an application parses a serialized protobuf message provided by an untrusted source. The attacker embeds a maliciously crafted length field in the protobuf wire format. When the decoder processes this field, the unchecked overflow allows the library to bypass memory bounds. Subsequently, the decoder may attempt to perform operations such as sub-slice creation, memory allocation, or pointer indexing based on the corrupted value.\nThis behavior can lead to several failure modes: 1) Unchecked exceptions leading to process termination; 2) Out-of-bounds behavior during buffer access; 3) Memory exhaustion via excessive allocation requests based on the inflated length. Because these conditions occur during the parsing stage, they do not require specific user privileges or authentication beyond the ability to interact with the service receiving the protobuf data.\nMultiple paths are susceptible, including those handling packed-repeated fields, nested messages, and size-delimited streams (e.g., ProtoDecoder.decodeSizeDelimited(_:from:)). The lack of strict verification against the remaining available buffer size permits the reader to cross the intended logical boundaries of the protobuf message structure, resulting in internal state corruption and subsequent application crashes."
}