Summary A flaw in the recvContent function allows a malicious AMQP server to trigger an Out-of-Memory (OOM) error, forcing the host operating system or container runtime to immediately terminate the client process.

Vulnerability Details When receiving message content payloads, the client processes the expected size from the content header framework. The recvContent function attempts to optimize performance by pre-allocating memory for the message body based on the ch.header.Size field, which is a 64-bit unsigned integer (uint64).

go // channel.go:495-496 if cap(ch.body) == 0 { ch.body = make([]byte, 0, ch.header.Size) // unbounded }

The underlying library fails to validate or cap this requested size against any upper boundary—such as the maximum frame size negotiated during connection establishment (FrameMax). If a server specifies an extreme body size (e.g., 2^62 bytes), the Go runtime attempts to allocate an exabyte-scale slice capacity. This immediately exhausts available system memory, causing the operating system's OOM killer to terminate the application.

Attack Vector / Exploitation Scenario

- Message Delivery Phase: A malicious or compromised AMQP broker sends a standard basic.deliver frame containing a content header with an intentionally inflated body-size variable. - Authentication Requirement: No special privileges or authentication bypasses are required; the crash occurs seamlessly during normal message consumption.

Impact

- Availability: High. Exploded memory consumption results in an instant process termination, destroying application state and availability for all threads sharing the environment.

Summary A Denial of Service (DoS) vulnerability exists in the AMQP client's connection negotiation logic. The AMQP specification explicitly mandates a strict minimum frame size of 4096 bytes to prevent pathological packet fragmentation. While the library defines a frameMinSize = 4096 constant, the connection negotiation loop fails to enforce this boundary, blindly accepting whatever maximum frame size (FrameMax) the server advertises during the handshake.

If a client connects to a malicious or compromised AMQP broker that advertises an extremely low FrameMax (such as 1 byte), the negotiation succeeds. Consequently, every subsequent message transmission is forced to splinter into thousands or millions of single-byte frames, causing massive CPU overhead, thread contention, and a near-instantaneous application freeze.

---

Vulnerability Details

Mechanism During the connection establishment phase, the client and server negotiate connection parameters—including maximum channel count, heartbeat intervals, and maximum frame sizes. The vulnerability is located where the client accepts the server's tuning parameters:

go // Connection negotiation logic maps server values directly without validation if serverSettings.FrameMax > 0 { // VULNERABILITY: Lacks a floor validation check against frameMinSize (4096) c.config.FrameMax = serverSettings.FrameMax }

Because there is no conditional check asserting that serverSettings.FrameMax >= frameMinSize, a value below the protocol specification floor is successfully registered. When the application later passes data payloads to the frame writer, the chunking algorithm splits the payload using the negotiated FrameMax value as its chunk window divisor.

Impact When FrameMax is set to an absurdly low threshold (e.g., 1 to 10 bytes): A standard 10 KiB message payload requires tens of thousands of individual write operations and frame headers. The system's CPU becomes entirely bound by frame serialization, memory allocation for frame structures, and context switching within the network output loops. This results in an application-layer Denial of Service (DoS) affecting not just the specific AMQP connection, but potentially the entire host system due to CPU resource starvation.

---

Attack Vector An attacker who compromises an upstream AMQP broker, performs a Man-in-the-Middle (MitM) interception, or tricks an application into connecting to an unauthorized external rogue broker can trigger this vulnerability:

1. Rogue Handshake: The client application connects to an AMQP endpoint controlled by the attacker. 2. Malicious Parameter Tuning: During the connection.tune phase, the rogue server returns a FrameMax value of 1. 3. Resource Exhaustion Trigger: The client completes the handshake successfully. As soon as the client attempts to publish a message or process traffic, the internal loop fragments the data into single-byte frames, spiking the host's CPU usage to 100% and disabling the application thread.

RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Channel.dispatch in channel.go, confirms.confirm in confirms.go, and Connection.dispatch0 in connection.go synchronously send publisher confirmations, flow-control events, consumer cancellations, returned messages, including NotifyConfirm events and connection block notifications, to application-provided channels. If a listener channel is unbuffered, full, or not drained promptly, the sole reader goroutine blocks and stops processing frames, acknowledgments, deliveries, and heartbeats. Broker-driven event bursts can therefore cause connection stalls, missed heartbeats, deadlocks, and disconnection. This issue is fixed in version 1.13.0.