
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 vulnerability in the readField function allows a malicious or compromised AMQP server to trigger an unhandled runtime panic in the client application, leading to an immediate crash of the entire process.
Details
When parsing incoming AMQP frames, the readField function processes byte-array fields (type tag 'x') by reading a 32-bit big-endian integer to determine the length of the data payload.
// read.go:253-263
case 'x':
var len int32
if err = binary.Read(r, binary.BigEndian, &len); err != nil {
return nil, err
}
value := make([]byte, len) // PANICS if len < 0
If a server transmits a length value of 0xFFFFFFFF, it is interpreted by the client as a signed 32-bit integer with a value of -1. Passing a negative integer to Go's built-in make() function for slice allocation triggers an unrecoverable runtime panic (panic: len out of range).
Because the reader goroutine handles network I/O without an explicit recover() wrapper, this panic propagates up to the runtime root, abruptly terminating the host application.
Attack Vector / Exploitation Scenario An attacker capable of spoofing, compromising, or controlling an AMQP broker can exploit this flaw during two primary phases:
Impact Availability: High. A single malformed frame can reliably crash the client process, resulting in a persistent Denial of Service (DoS) if the client automatically reconnects and receives the same payload.
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.