amqp091-go EUVD-2026-80818

Exploitation requires ALL of: (1) the affected application is built with a Go runtime whose crypto/tls defaults permit TLS 1.0 or TLS 1.1 - modern Go toolchains that enforce a TLS 1.2 minimum are NOT exploitable, making this the dominant limiter; (2) the client connects using an amqps:// URI whose tls.Config is produced by the library's tlsConfigFromURI path (i.e. not a user-supplied tls.Config that already sets MinVersion); and (3) an active man-in-the-middle attacker positioned on the network path who can influence the TLS handshake to force the obsolete-protocol downgrade. Passive eavesdropping alone is insufficient; the attacker must actively manipulate negotiation. This is not remote-unauthenticated exploitation against a default modern deployment - the legacy-Go-build precondition and required MITM foothold together sharply narrow real-world exposure.

This is a classic case of an inflated CVSS score masking modest real-world risk. The vendor CVSS 4.0 of 9.4 is not credible for a TLS-downgrade weakness: it claims VC:H/VI:H/SC:H, yet the flaw only enables an obsolete protocol to be negotiated and requires two independent, non-trivial preconditions reflected in the vector itself (AC:H + AT:P). Exploitation depends on (1) the application being compiled with a Go runtime whose defaults permit TLS 1.0/1.1 - modern Go toolchains (roughly Go 1.22+) already enforce a TLS 1.2 minimum, so the majority of current builds are NOT affected - and (2) an active on-path (MITM) attacker positioned to influence TLS negotiation and force the downgrade. There is no EPSS score, no CISA KEV listing, and no public exploit code, so this is 'no public exploit identified at time of analysis.' PR:N is confirmed by the vector (network attacker, no credentials), but note the attacker must already hold a privileged network position, which is a real limiter that CVSS attack-vector alone does not convey. Bottom line: a legitimate hardening fix, but a low operational priority - treat the 9.4 as over-scored and prioritize based on whether you run legacy Go builds and face MITM exposure. The primary impact is confidentiality of AMQP messages/credentials with limited integrity exposure, not the full high-triad the vendor asserts.

An attacker with a man-in-the-middle position on the network path between an amqp091-go client (built with an older Go runtime that still permits TLS 1.0/1.1) and its RabbitMQ broker interferes with the TLS handshake to force negotiation of an obsolete protocol version. With the downgraded, weaker transport in place, the attacker can attempt to decrypt or tamper with AMQP traffic, exposing message contents and broker credentials. No public proof-of-concept exists, and the attack is opportunistic - it requires both the legacy build condition and an active in-path foothold.