criticalCVE-2026-77405Sep 17, 2026

CVE-2026-77405: amqp091-go TLS Version Downgrade via Missing MinVersion

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

The RabbitMQ Go AMQP client built on legacy Go runtimes could silently accept TLS 1.0 or 1.1 connections because the library never pinned a minimum TLS version, letting a network attacker downgrade…

Packagegithub.com/rabbitmq/amqp091-go
Ecosystemgo
Affected< 1.13.0
Fixed in1.13.0

The problem

In uri.go, the tlsConfigFromURI function built a *tls.Config struct for every amqps:// connection without setting the MinVersion field. Leaving MinVersion at its zero value defers the floor to whatever the Go runtime defaults to.

On Go runtimes older than 1.18, that default allowed negotiation down to TLS 1.0. Any application compiled against a legacy toolchain or a custom Go distribution was quietly exposed, with no warning and no compile-time guard.

Proof of concept

A working proof-of-concept for CVE-2026-77405 in github.com/rabbitmq/amqp091-go, with the exact payload below.

go
// Vulnerable code in uri.go (< 1.13.0)
// tlsConfigFromURI builds tls.Config without pinning MinVersion.
// An attacker performing a TLS downgrade attack intercepts the handshake
// and forces the client to accept TLS 1.0 when built with Go < 1.18.

cfg := &tls.Config{
    ServerName: host,
    // MinVersion not set; defaults to 0 (runtime-chosen)
    // On Go < 1.18 this allows TLS 1.0 / 1.1
}

// Attack: connect a rogue broker that advertises only TLS 1.0.
// Client dials: amqps://user:pass@attacker-broker:5671/
// Handshake completes at TLS 1.0 -> BEAST/POODLE apply.
// Credentials and AMQP frames are now decryptable in transit.

// Fix applied in commit c9fd433 (PR #355):
cfg := &tls.Config{
    ServerName: host,
    MinVersion: tls.VersionTLS12, // explicit floor added by patch
}

The root cause is CWE-326 (Inadequate Encryption Strength) combined with CWE-312 (Cleartext Storage of Sensitive Information in Memory, since downgraded sessions expose credentials). Setting MinVersion to 0 in Go's crypto/tls is not a safe default; it hands version selection entirely to the runtime, making the library's security posture a build-time artifact rather than a code-level guarantee.

The patch in commit c9fd433 (PR #355 by @suchitd) is a one-line change: adding MinVersion: tls.VersionTLS12 to the tls.Config literal inside tlsConfigFromURI. This hard-codes the floor in the library itself, independent of the compiler version used to build the consuming application.

The fix

Upgrade to github.com/rabbitmq/amqp091-go v1.13.0 or later. The fix is in commit c9fd433ecac2e557919e51acc9d809390c402c6e (PR #355). If an immediate upgrade is not possible, construct your own tls.Config with MinVersion: tls.VersionTLS12 and pass it via amqp.DialTLS instead of using an amqps:// URI.

Reported by suchitd (RabbitMQ team).

References: [1][2][3][4][5][6]

Related research