NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

RabbitMQ amqp091-go: Missing Explicit TLS Minimum Version Configuration In URI ParserGHSA-33mj-cw25-m34h

Fix: rabbitmq/amqp091-go#355

GHSA-33mj-cw25-m34h 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.

Also known asCVE-2026-77405GO-2026-6492
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 31, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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 GHSA-33mj-cw25-m34h.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs21th percentile — riskier than 21% of all scored CVEsHighest risk
0.00%0.26%0.52%0.78%0.3%0.3%Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐹github.com/rabbitmq/amqp091-go

Real-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:

  1. Interception: A client application compiled on a legacy pipeline attempts to establish an encrypted connection to an AMQP broker.
  2. Protocol Downgrade: The attacker intercepts the TLS Client Hello handshake and forces a downgrade negotiation to TLS 1.0.
  3. Cryptographic Exploitation: Because MinVersion was never explicitly locked to tls.VersionTLS12 by the library, the client accepts the weak cipher suites, allowing the attacker to monitor or manipulate the underlying AMQP session data.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/rabbitmq/amqp091-goall versions1.13.0go get github.com/rabbitmq/amqp091-go@v1.13.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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 GHSA-33mj-cw25-m34h is resolved across your whole dependency graph.

  3. 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.

Red HatImportant

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…

Workaround published by Red Hat
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 GHSA-33mj-cw25-m34h (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Advanced Cluster Management for Kubernetes 2.13rhacm2/acm-grafana-rhel9:1792865487RHSA-2026:92307

Frequently Asked Questions

## 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
O3 Security · Impact-Aware SCA

Is GHSA-33mj-cw25-m34h in your dependencies?

Find it across Go, including transitive dependencies.

RabbitMQ amqp091-go: Missing Explicit TLS Minimum…