amqp091-go CVE-2026-79921

Exploitation requires that the victim Go application connects to an AMQP broker controlled by or compromised by the attacker - this is the specific prerequisite captured by AT:P in the CVSS 4.0 vector. An application connecting only to a trusted, internally managed RabbitMQ instance with no external exposure cannot be exploited by remote third parties. The vulnerability is triggered during the standard AMQP TUNE handshake on any connection attempt, requiring no special client-side configuration, feature flag, or non-default setting - default connection behavior is affected. Authentication requirements are not applicable from the attacker's perspective because the attacker controls the server side of the connection. Exploitation is bounded by: (1) the attacker's ability to position a malicious or compromised broker reachable by the target client, and (2) the client running amqp091-go versions prior to 1.13.0. Clients in fully isolated environments connecting exclusively to operator-controlled brokers face negligible realistic risk.

The CVSS 4.0 score of 8.9 reflects a network-reachable attack vector (AV:N) with low complexity (AC:L), but the AT:P metric (attack requirements present) is the critical risk moderator: exploitation requires the victim client to connect to a broker that is either controlled by the attacker or has been compromised. This prerequisite substantially limits real-world exposure - Go applications connecting exclusively to internally managed, trusted RabbitMQ instances operated by the same organization are not externally exploitable. The high availability impact on both the vulnerable system (VA:H) and subsequent systems (SA:H) is realistic, as unbounded Go heap allocation can exhaust process memory and crash the host application. No EPSS score was provided in the input data; the absence of KEV listing and public exploit code suggests this has not been widely targeted. Real-world priority is moderate: treat as high for services that might connect to external, shared, or third-party-operated AMQP brokers, and lower for fully air-gapped internal deployments - though prompt patching is still warranted given the trivial fix cost.

An attacker who operates or has compromised an AMQP broker sends a crafted TUNE response during the connection handshake, advertising a frame_max value designed to cause the client to accept and allocate memory for content body frames that violate the protocol's framing constraints. The amqp091-go client before v1.13.0 accepts this value without enforcing the specification minimum, triggering unbounded heap allocation as the client processes the malformed frames, ultimately exhausting process memory and crashing the application. No public proof-of-concept exploit exists at time of analysis.