amqp091-go TLS Client Lacks Explicit Minimum Version, Enabling Downgrade Risk on Legacy Builds

A new GitHub Security Advisory (GHSA-33mj-cw25-m34h, tracked as CVE-2026-77405) flags a structural weakness in github.com/rabbitmq/amqp091-go, the Go client library for RabbitMQ's AMQP 0-9-1 protocol. According to the advisory, the client's tlsConfigFromURI function builds a *tls.Config for amqps:// connections without explicitly setting MinVersion. The advisory states that on Go 1.18+ toolchains this defaults to TLS 1.2, but the safety floor is implicit rather than enforced in the library's own code — meaning applications built with a pre-1.18 Go toolchain, or any future toolchain that changes its default, could silently permit negotiation down to TLS 1.0 or 1.1. A public PoC is noted as available; no CVSS score has been published yet.

Why It Matters

This is not a remote-triggerable flaw in the traditional sense — it's a missing hardening control whose actual risk depends entirely on the Go toolchain version used to build the consuming application. Organizations running services that connect to RabbitMQ brokers via amqp091-go, especially anything built on older pipelines, container base images, or vendored/frozen Go versions, could be exposed to a TLS downgrade if an attacker can position themselves for a man-in-the-middle attack against the broker connection. A successful downgrade to TLS 1.0/1.1 opens the door to known cryptographic attacks (e.g. BEAST, POODLE, SWEET32) against AMQP session traffic, potentially exposing message payloads and broker credentials in transit.

What Defenders Should Do Now

• Inventory services using github.com/rabbitmq/amqp091-go and check the Go toolchain version they were compiled with — anything below Go 1.18 is the primary concern per the advisory.
• Watch for an upstream patch that explicitly pins MinVersion: tls.VersionTLS12 (or higher) in the library itself, and prioritize upgrading once available rather than relying on toolchain defaults.
• Where feasible, enforce TLS version floors at the network layer (broker-side TLS policy, load balancer/proxy termination, or service mesh mTLS config) as a defense-in-depth measure independent of client library behavior.
• Hunt for anomalous TLS handshake negotiations to RabbitMQ brokers — specifically connections settling on TLS 1.0/1.1 where TLS 1.2+ is expected — and enable broker-side logging/alerting on downgraded handshakes if your broker supports it.
• Review CI/build pipelines to confirm current Go toolchain usage and pin a minimum supported Go version for any service depending on this library.

This is developing intel published same-day based on a single advisory; details such as an official patch version and CVSS scoring were not yet available at time of writing. For the full technical write-up, see the original GitHub Security Advisory: GHSA-33mj-cw25-m34h.