CVE-2026-77409 in amqp091-go
Summary
by MITRE • 09/16/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in RabbitMQ amqp091-go versions prior to 1.13.0 stems from a synchronous processing model for broker-driven events within the client library's core connection and channel management logic. Specifically, functions such as Channel.dispatch, confirms.confirm, and Connection.dispatch0 are responsible for handling publisher confirmations, flow-control events, consumer cancellations, returned messages, NotifyConfirm events, and connection block notifications. In these earlier versions, the implementation of these handlers operates synchronously on the single reader goroutine that is dedicated to processing incoming frames from the RabbitMQ broker. This architectural design assumes that application-provided listener channels are either buffered or will be drained promptly by the consuming application code. When this assumption does not hold true, specifically when a listener channel is unbuffered, full, or blocked due to slow consumer processing, the synchronous nature of these event handlers causes the reader goroutine to block indefinitely while waiting for space in the channel buffer or for the application to consume the data.
This blocking behavior has severe operational consequences for any system relying on this client library. Because the single reader goroutine is occupied with handling high-volume broker events rather than processing essential protocol frames, it fails to read acknowledgments, message deliveries, and critical heartbeats from the connection. The inability to process heartbeat messages leads directly to missed heartbeats, which triggers the RabbitMQ broker to terminate the TCP connection as a precaution against stale or unresponsive clients. Furthermore, if multiple goroutines are waiting on blocked channels or if the deadlock propagates through application logic dependent on these events, it can result in complete deadlocks within the Go runtime environment of the client application. This effectively causes service outages where applications appear to hang or disconnect unexpectedly during periods of high message throughput or bursty traffic patterns from the broker.
From a security and reliability perspective, this flaw represents a significant availability risk rather than a direct confidentiality or integrity breach. It aligns with CWE-400, which describes uncontrolled resource consumption, as the application's inability to manage channel buffers leads to thread starvation and resource exhaustion in the form of blocked goroutines that cannot proceed. In terms of adversary behavior simulation using MITRE ATT&CK techniques, this vulnerability could be leveraged by an attacker who can control or influence message volume sent through RabbitMQ channels. By generating a burst of publisher confirmations or returned messages, an attacker could induce a denial-of-service condition against the client application without needing to exploit any authentication weaknesses or inject malicious payloads into the data stream itself. The attack vector relies on overwhelming the synchronous event handlers with legitimate but high-frequency broker events, thereby exploiting the lack of asynchronous buffering in the library's design prior to version 1.13.0.
The resolution for this issue was implemented in RabbitMQ amqp091-go version 1.13.0 by modifying the dispatch logic to handle these events asynchronously or with appropriate non-blocking mechanisms that prevent the reader goroutine from being permanently stalled by slow consumer channels. To mitigate this vulnerability, organizations must ensure they upgrade their Go dependencies to include at least version 1.13.0 of the amqp091-go library. Additionally, application developers should review their usage of listener channels and implement proper buffering strategies where upgrading is not immediately feasible, ensuring that channel buffers are sized appropriately for expected event volumes or that consumers drain these channels rapidly enough to prevent blocking. Regular dependency audits and automated vulnerability scanning tools configured with updated CVE databases can help identify systems still running the affected versions in production environments.