
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: < 1.13.0
Patched in 1.13.0
Details
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:
// 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:
return statement."", nil (indicating a successful read of an empty string).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.
connection.close, channel.open, or message publishing frames), forcing the client/server to execute unintended actions.EPSS, exploit probability
Low0.52%
estimated chance of real-world exploitation in the next 30 days, higher than 44.4% of every CVE FIRST.org scores
Refreshed 11/1/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.