CVE-2026-79921: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-79921 is a denial-of-service vulnerability in amqp091-go, the official Go AMQP 0.9.1 client library maintained by RabbitMQ. A compromised or malicious AMQP broker can force the client to allocate memory for and process content body frames that exceed the negotiated frame_max limit, bypassing the protocol's built-in framing constraints. All versions of amqp091-go prior to 1.13.0 are affected. The advisory was published on July 22, 2026, and the CVE was disclosed on August 26, 2026. It carries a CVSS v4.0 base score of 8.9 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-770 (Allocation of Resources Without Limits or Throttling). During the AMQP 0-9-1 connection handshake, the client and broker negotiate a maximum frame size (frame_max, e.g., 4096 bytes). However, the vulnerable client code used a pick() function that simply selected the minimum of the client and server values without enforcing the AMQP specification's minimum floor of 4096 bytes (frameMinSize). A malicious broker could send a basic.deliver sequence containing a content body frame whose declared payload size exceeds the negotiated frame_max; instead of closing the connection with a frame-error as required by the AMQP 0-9-1 spec, the client accepted the oversized declaration, allocated memory accordingly, and delivered the message to the consumer. The fix, introduced in PR #353, extracts frame size negotiation into a dedicated negotiateFrameSize() function that enforces the minimum floor (GitHub Advisory, Fix PR, Fix Commit).

Successful exploitation can cause significant unexpected memory consumption on the client side, potentially leading to Out-Of-Memory (OOM) crashes and application-layer denial of service. The vulnerability affects availability of systems using the amqp091-go client library; there is no confidentiality or integrity impact. Because the attack requires a compromised or malicious AMQP broker — meaning the broker itself must be under attacker control or substituted — the blast radius is limited to clients connected to that broker, but in microservice architectures this could affect multiple downstream consumers simultaneously (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, reflecting very low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to control or compromise the AMQP broker that the target client connects to (Attack Requirements: Present), which limits opportunistic exploitation but remains a realistic threat in supply-chain or man-in-the-middle scenarios (GitHub Advisory).

1. Gain broker control: Compromise or operate a malicious AMQP 0.9.1 broker, or position the attacker between a legitimate client and broker (e.g., via DNS spoofing, BGP hijacking, or supply-chain compromise of the broker infrastructure).
2. Complete connection handshake: Allow the client to connect and complete the standard AMQP 0-9-1 handshake, during which a frame_max value is negotiated (e.g., 4096 bytes).
3. Send oversized content body frame: After negotiation, craft and send a basic.deliver sequence where the content body frame header declares a payload size significantly larger than the negotiated frame_max (e.g., hundreds of megabytes or gigabytes).
4. Trigger excessive allocation: The vulnerable client (pre-1.13.0) accepts the broker-declared size without validation, allocates memory based on the oversized declaration, and attempts to read and assemble the payload — consuming available system memory.
5. Achieve DoS: Repeat or scale the oversized frame delivery to exhaust client memory, causing OOM crashes or severe performance degradation of the consuming application (GitHub Advisory, Fix PR).

• Process: Go application processes using amqp091-go exhibiting rapidly increasing memory consumption without a corresponding increase in legitimate message throughput; OOM killer events (oom-kill) in system logs targeting the AMQP consumer process.
• Logs: Application logs showing unexpected large message deliveries or memory allocation errors from the AMQP client; Go runtime panic messages related to memory exhaustion.
• Network: AMQP traffic (typically TCP port 5672 or 5671 for TLS) containing content body frames with declared sizes far exceeding the negotiated frame_max; anomalous broker behavior such as unexpected basic.deliver sequences with abnormally large content headers.
• System: Sudden spikes in system memory usage correlated with AMQP connection activity; kernel OOM events or process restarts of AMQP consumer services.

Upgrade amqp091-go to version 1.13.0 or later, which introduces the negotiateFrameSize() function that enforces the AMQP specification's minimum frame size floor and rejects frames exceeding the negotiated frame_max before allocation (v1.13.0 Release, Fix Commit). The maintainers have confirmed no known workarounds are available for unpatched versions. As a defense-in-depth measure, restrict AMQP broker connections to trusted, verified sources and implement network segmentation to limit client exposure to potentially compromised brokers (GitHub Advisory).