CVE-2026-77411

**Summary** A critical stream desynchronization vulnerability has been identified in the AMQP wire-protocol parser. When parsing a long string (`readLongstr`) within a table field, providing a length that exceeds the maximum signed 32-bit integer (`2^31 - 1`, or roughly `2.1` GiB) triggers an improper error-handling condition. The parser abruptly aborts the read and returns a success status (`"",nil`) without consuming the specified bytes from the underlying network buffer. This causes all subsequent read operations to become misaligned. The parser interprets arbitrary offsets within the remaining payload bytes as valid AMQP frame headers, leading to potential Remote Code Execution (RCE), data injection, or complete connection hijacking. **Vulnerability Details** The vulnerability exists within the bounds-checking logic of the readLongstr function: ```go // read.go:113-114 — silent no-op return, bytes left in stream if length > (^uint32(0) >> 1) { return // returns "", nil, does NOT consume `length` bytes } ``` When `length` evaluates to a value greater than `0x7FFFFFFF`: 1. The function executes a silent `return` statement. 2. Because Go utilizes named or zero-value initialization for unassigned return registers, this yields `"", nil` (indicating a successful read of an empty string). 3. The Critical Failure: The reader's cursor is not advanced by `length` bytes. The malformed payload remains sitting in the TCP/buffer stream. **Impact** As `readTable` continues iterating over the stream under the assumption that the string was successfully parsed, the byte alignment is entirely broken. - Parser Desynchronization: Future AMQP frame headers are read from arbitrary offsets inside the attacker-controlled message payload. - Payload Reinterpretation: A malicious actor can carefully craft the trailing bytes of the initial payload to perfectly mimic valid AMQP frames (e.g., `connection.close`, `channel.open`, or message publishing frames), forcing the client/se