CVE-2026-77405: RabbitMQ amqp091-go TLS Protocol Weakness

CVE-2026-77405 Overview

CVE-2026-77405 affects amqp091-go, the official Go client library for RabbitMQ's Advanced Message Queuing Protocol (AMQP) 0.9.1. The tlsConfigFromURI function in uri.go constructs tls.Config values without setting MinVersion to tls.VersionTLS12. Applications built with a Go runtime whose default permits TLS 1.0 or TLS 1.1 can negotiate an obsolete protocol version when connecting through an amqps:// URI. An attacker positioned to influence TLS negotiation can weaken transport protection for AMQP messages and credentials in transit. The issue is fixed in version 1.13.0 and is classified under [CWE-326: Inadequate Encryption Strength].

Critical Impact
Downgrade of AMQP transport encryption to obsolete TLS 1.0/1.1, exposing message contents and broker credentials to network attackers.

Affected Products

RabbitMQ amqp091-go client versions prior to 1.13.0
Go applications using amqps:// URIs with tlsConfigFromURI
Deployments built against Go runtimes that permit TLS 1.0 or TLS 1.1 defaults

Discovery Timeline

2026-09-16 - CVE-2026-77405 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-77405

Vulnerability Analysis

The amqp091-go library parses amqps:// connection URIs through the tlsConfigFromURI helper. This helper returns a *tls.Config populated with server name and optional certificate material, but it does not assign a value to the MinVersion field. When MinVersion is left at its zero value, Go's crypto/tls package falls back to the runtime default minimum, which historically permits TLS 1.0 and TLS 1.1.

Builds compiled with older Go toolchains, or with GODEBUG=tls10default=1 style overrides, therefore accept legacy protocol versions during the ClientHello handshake with the RabbitMQ broker. AMQP payloads frequently carry authentication credentials via PLAIN SASL and confidential message bodies, so weakening the transport channel exposes both authentication material and application data.

Root Cause

The root cause is a missing secure default in transport configuration. tlsConfigFromURI constructs the configuration structure but omits MinVersion: tls.VersionTLS12, deferring the decision to the runtime. The fix in pull request #355 documents that callers of DialTLS must supply a secure MinVersion and updates the library to enforce TLS 1.2 as the floor when the client builds the config from the URI.

Attack Vector

An attacker with a network position between the AMQP client and broker can influence the TLS handshake to downgrade the negotiated version to TLS 1.0 or TLS 1.1. Once the channel uses an obsolete protocol, known weaknesses in legacy cipher suites and record protection can be leveraged to recover plaintext or credentials. The attack requires the client to be built against a Go runtime that still permits legacy TLS versions, which explains the high attack complexity reflected in the scoring vector.

// seconds and sets the initial read deadline to 30 seconds.
//
// DialTLS uses the provided tls.Config when encountering an amqps:// scheme.
// Note: If you provide a custom tls.Config, you should explicitly set a secure
// MinVersion (such as tls.VersionTLS12 or tls.VersionTLS13) as the library
// does not override it.
func DialTLS(url string, amqps *tls.Config) (*Connection, error) {
    return DialConfig(url, Config{
        TLSClientConfig: amqps,
    })
}

Source: GitHub Commit c9fd433

Detection Methods for CVE-2026-77405

Indicators of Compromise

AMQP broker logs recording client handshakes that negotiate TLS 1.0 or TLS 1.1 on port 5671
Network sensors observing ClientHello messages with supported_versions extensions advertising legacy TLS to RabbitMQ endpoints
Software bills of materials referencing github.com/rabbitmq/amqp091-go at versions earlier than v1.13.0

Detection Strategies

Inventory Go binaries and dependency manifests (go.mod, go.sum) for amqp091-go versions prior to 1.13.0.
Enable RabbitMQ server-side TLS logging and alert on any successful handshake below TLS 1.2.
Perform passive TLS fingerprinting on AMQPS traffic to flag deprecated protocol versions.

Monitoring Recommendations

Aggregate broker connection logs into a central analytics store and query for negotiated protocol version fields.
Track outbound TLS negotiation metadata from application hosts that connect to messaging infrastructure.
Alert on any deviation from a TLS 1.2 or TLS 1.3 baseline for AMQPS sessions.

How to Mitigate CVE-2026-77405

Immediate Actions Required

Upgrade github.com/rabbitmq/amqp091-go to version v1.13.0 or later in all Go projects.
Rebuild and redeploy services that consume the library so the fixed code path is loaded.
Configure the RabbitMQ broker to reject connections below TLS 1.2 to enforce defense in depth.

Patch Information

The fix is delivered in amqp091-go v1.13.0 via Pull Request #355. The change explicitly sets MinVersion to tls.VersionTLS12 in tlsConfigFromURI and documents the requirement for callers supplying custom tls.Config values. Additional context is available in the GitHub Security Advisory GHSA-33mj-cw25-m34h.

Workarounds

Pass an explicit tls.Config with MinVersion: tls.VersionTLS12 to DialTLS or DialConfig when upgrading is not immediately possible.
Disable TLS 1.0 and TLS 1.1 on RabbitMQ brokers via the ssl_options.versions setting to prevent legacy negotiation.
Restrict AMQPS listener acceptance to modern cipher suites and versions at the network load balancer.

bash

# RabbitMQ broker configuration to enforce modern TLS
# /etc/rabbitmq/rabbitmq.conf
listeners.ssl.default = 5671
ssl_options.versions.1 = tlsv1.3
ssl_options.versions.2 = tlsv1.2
ssl_options.fail_if_no_peer_cert = false