CVE-2026-77405 — amqp091-go
Fix: rabbitmq/amqp091-go@c9fd433CVE-2026-77405 is a CWE-326 vulnerability in github.com/rabbitmq/amqp091-go. A fix is available for github.com/rabbitmq/amqp091-go — see the affected versions and patch details below.
RabbitMQ amqp091-go: Missing Explicit TLS Minimum Version Configuration In URI Parser
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-77405.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
github.com/rabbitmq/amqp091-goReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A structural security weakness exists in the AMQP client's TLS configuration generator (tlsConfigFromURI). When constructing a *tls.Config object from an amqps:// connection URI, the library initializes the structure without explicitly defining the MinVersion field.
While modern versions of the Go compiler toolchain (Go 1.18+) default the implicit minimum version to TLS 1.2, this security posture relies entirely on an implicit toolchain dependency. If the library is compiled using legacy Go toolchains (Go < 1.18), or if a future toolchain introduces fallback behavior, the client could silently negotiate obsolete and insecure TLS 1.0 or TLS 1.1 protocols during connection handshakes with a compromised or malicious AMQP broker.
Vulnerability Details
Mechanism
The vulnerability lies in the lack of an explicit safety floor when assigning configurations inside the URI component:
// Example within uri.go's tlsConfigFromURI
cfg := &tls.Config{
ServerName: host,
// MinVersion is left completely unassigned (defaults to 0, or toolchain default)
}
In the Go standard library (crypto/tls), leaving MinVersion: 0 instructs the runtime to choose the toolchain's default minimum. Prior to Go 1.18, this default allowed negotiation down to TLS 1.0. Relying on implicit compiler configurations violates secure coding practices by decoupling the library's security posture from its source code, leaving applications vulnerable based solely on how they are built.
Impact
If a client application is built with a legacy compiler environment or a custom Go runtime, an attacker capable of executing a Man-in-the-Middle (MitM) attack can force the connection to downgrade to TLS 1.0 or 1.1. This exposes the AMQP protocol data stream to well-known cryptographic vulnerabilities (such as BEAST, POODLE, or SWEET32), allowing the attacker to decrypt or alter message payloads, connection parameters, and authentication credentials.
Attack Vector
An attacker performing a network-level downgrade attack can intercept a client connection built under a legacy toolchain:
- Interception: A client application compiled on a legacy pipeline attempts to establish an encrypted connection to an AMQP broker.
- Protocol Downgrade: The attacker intercepts the TLS Client Hello handshake and forces a downgrade negotiation to TLS 1.0.
- Cryptographic Exploitation: Because
MinVersionwas never explicitly locked totls.VersionTLS12by the library, the client accepts the weak cipher suites, allowing the attacker to monitor or manipulate the underlying AMQP session data.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/rabbitmq/amqp091-go | all versions | 1.13.0go get github.com/rabbitmq/amqp091-go@v1.13.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/rabbitmq/amqp091-go, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/rabbitmq/amqp091-go to 1.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-77405 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This flaw has an Important impact. Red Hat product streams that ship amqp091-go before 1.13.0 are Affected because tlsConfigFromURI does not set an explicit TLS MinVersion when parsing AMQPS URIs. Exploitation requires a man-in-the-middle position on the path to the AMQP broker; Go 1.18 or later client defaults…
Ensure clients are built with Go 1.18 or later so the TLS client default is at least TLS 1.2. Restrict AMQP clients to trusted brokers and limit broker network exposure. If using DialTLS with a custom tls.Config, set MinVersion to tls.VersionTLS12 or higher explicitly.Source: Red Hat security advisory for CVE-2026-77405 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Advanced Cluster Management for Kubernetes 2.13 | rhacm2/acm-grafana-rhel9:1792865487 | RHSA-2026:92307 |
Frequently Asked Questions
Is CVE-2026-77405 in your dependencies?
Find it across Go, including transitive dependencies.