CVE-2026-77409: RabbitMQ amqp091-go DOS Vulnerability

CVE-2026-77409 Overview

CVE-2026-77409 affects amqp091-go, the official Go client for RabbitMQ implementing the AMQP 0.9.1 protocol. Versions prior to 1.13.0 dispatch broker-driven events synchronously to application-provided Go channels. When a listener channel is unbuffered, full, or not drained promptly, the sole reader goroutine blocks and stops processing frames, acknowledgments, deliveries, and heartbeats. Attackers or bursty broker traffic can trigger connection stalls, missed heartbeats, deadlocks, and forced disconnection. The issue is classified under [CWE-770] (Allocation of Resources Without Limits or Throttling) and is fixed in version 1.13.0.

Critical Impact
A single slow or unbuffered listener channel can stall the entire AMQP connection, causing missed heartbeats and denial of service for all consumers and publishers sharing that connection.

Affected Products

RabbitMQ amqp091-go client library, all versions prior to 1.13.0
Go applications using Channel.NotifyPublish, NotifyFlow, NotifyCancel, NotifyReturn, or NotifyBlocked
Downstream services depending on vulnerable amqp091-go releases

Discovery Timeline

2026-09-16 - CVE-2026-77409 published to NVD
2026-09-16 - Last updated in NVD database
Fix released - amqp091-go version 1.13.0 published on GitHub

Technical Details for CVE-2026-77409

Vulnerability Analysis

The amqp091-go library uses a single reader goroutine per connection to demultiplex incoming AMQP frames. That goroutine dispatches events synchronously into application-supplied Go channels registered through the Notify* APIs. Synchronous channel sends block indefinitely when the receiving channel is unbuffered or full. During a burst of broker events, a single unresponsive listener stalls the reader goroutine. The reader then fails to process heartbeats, publisher acknowledgments (basic.ack), deliveries, and returned messages. The broker eventually terminates the connection due to missed heartbeats, producing a denial-of-service condition across all channels multiplexed over the same connection.

Root Cause

The root cause is unbounded blocking on channel sends in Channel.dispatch (channel.go), confirms.confirm (confirms.go), and Connection.dispatch0 (connection.go). The library trusted application code to always drain notification channels promptly. No timeout or non-blocking send guarded the dispatch path, so any slow consumer could block the shared reader.

Attack Vector

The vulnerability is reachable over the network. An attacker able to induce broker-driven event bursts, such as flow-control transitions, message returns, or high-throughput publisher confirms, can force the reader goroutine to block on a listener channel. Even without a malicious actor, ordinary application bugs like a paused consumer produce the same denial-of-service outcome.

// Patch excerpt from channel.go - Avoid notifications blocking reader.
case *channelFlow:
    ch.notifyM.RLock()
    for _, c := range ch.flows {
-       c <- m.Active
+       select {
+       case c <- m.Active:
+       case <-time.After(5 * time.Second):
+       }
    }
    ch.notifyM.RUnlock()
    if err := ch.send(&channelFlowOk{Active: m.Active}); err != nil {

Source: GitHub Commit 5b0ccbb

Detection Methods for CVE-2026-77409

Indicators of Compromise

Repeated AMQP connection drops with missed heartbeats from client, timeout: 60s messages in RabbitMQ broker logs.
Go application goroutine dumps showing the reader stuck on a channel send in Channel.dispatch, confirms.confirm, or Connection.dispatch0.
Sudden halt of publisher confirm delivery or consumer message flow despite broker availability.

Detection Strategies

Inventory Go build manifests (go.mod, go.sum) across services for github.com/rabbitmq/amqp091-go versions below 1.13.0.
Instrument applications with runtime profiling (pprof) to identify goroutines blocked on notification channel sends.
Correlate broker-side connection resets with client-side reader-goroutine stalls to confirm exploitation of the blocking condition.

Monitoring Recommendations

Alert on unexpected spikes in RabbitMQ connection_closed events tied to heartbeat timeouts.
Track queue depth and consumer utilization to flag stalled consumers that would trigger the blocking dispatch path.
Ingest broker and application logs into a centralized analytics platform to correlate reader-goroutine stalls with broker-driven event bursts.

How to Mitigate CVE-2026-77409

Immediate Actions Required

Upgrade github.com/rabbitmq/amqp091-go to version 1.13.0 or later in all Go services.
Audit every call to NotifyPublish, NotifyFlow, NotifyCancel, NotifyReturn, and NotifyBlocked to ensure buffered channels and prompt drainage.
Redeploy affected services after dependency updates and verify heartbeat stability against the broker.

Patch Information

The fix is available in amqp091-go v1.13.0. The patch introduces bounded, timeout-guarded sends on notification channels so the reader goroutine can never block indefinitely. See the GitHub Security Advisory GHSA-wxx3-cj7g-w73j and Pull Request #349 for the full change set.

Workarounds

Provision notification channels with sufficient buffer capacity to absorb broker event bursts.
Run dedicated goroutines that continuously drain each Notify* channel, discarding events the application does not consume.
Reduce publisher confirm throughput or disable notifications that are not required until the upgrade is deployed.

bash

# Upgrade the amqp091-go dependency to the patched release
go get github.com/rabbitmq/amqp091-go@v1.13.0
go mod tidy
go build ./...