Summary

A structural Denial of Service (DoS) vulnerability exists in the AMQP client implementation's event dispatch architecture. The single, internal reader goroutine responsible for processing all incoming network frames dispatches event notifications to user-allocated channels synchronously.

If a client application registers an unbuffered or inadequately buffered channel for notifications (such as publisher confirmations, flow control, consumer cancellations, or connection blocks), a burst of events from the AMQP server will cause the reader goroutine to block indefinitely while waiting for the application to drain the channel. This completely halts the connection's frame-processing loop, leading to connection timeouts, missed heartbeats, and client-side deadlocks.

Vulnerability Details

The AMQP client utilizes a central reader goroutine to ingest frames from the network socket and route them to their respective handlers. However, several critical event notification paths transmit data directly to client-provided channels within this single goroutine's execution thread:

// confirms.go:64-66
for _, l := range c.listeners {
    l <- confirmation  // BLOCKS the entire reader goroutine if the channel buffer is full
}

Because the send operation l <- confirmation is synchronous and lacks a timeout or select-default fallback, the entire connection multiplexer relies on the promptness of the application-level consumer.

Affected Dispatch Paths

The vulnerability propagates across multiple event-handling subsystems:

• Publisher Confirms: confirms.confirm() -> l <- confirmation (confirms.go:65)
• Channel Flow Controls: channelFlow -> c <- m.Active (channel.go:370)
• Consumer Cancellations: basicCancel -> c <- m.ConsumerTag (channel.go:380)
• Returned Messages: basicReturn -> c <- *ret (channel.go:388)
• Connection Block/Unblock States: connectionBlocked/Unblocked -> c <- Blocking{...} (connection.go:849, 853)

Impact

When the reader goroutine blocks, all low-level protocol operations for that network connection cease entirely. The client stops responding to server heartbeats, fails to process incoming ACKs/NACKs, and cannot read new message deliveries. Ultimately, the AMQP broker will drop the connection due to missing heartbeats, resulting in application disruption and connection instability.

Attack Vector

An attacker capable of influencing broker activity (or a malicious broker) can intentionally trigger this condition to force client disconnection or message processing stagnation:

1. Targeting Publisher Confirms: An application registers a NotifyConfirm channel with a standard buffer size of 1.
2. Event Burst: The server or an attacker flooding a queue causes the broker to emit a swift burst of acknowledgments (e.g., 100 ACKs).
3. Denial of Service: The client application fails to read from the channel faster than the burst arrival rate. The internal reader goroutine blocks on the second acknowledgment, freezing the entire connection until the heartbeat interval expires and the broker forcefully tears down the socket.