RabbitMQ amqp091-go EUVD-2026-80810

Exploitation requires the vulnerable amqp091-go client (prior to 1.13.0) to establish an AMQP 0.9.1 connection to a broker that is malicious or has been compromised (or to a broker connection an attacker can actively tamper with); the attacker-controlled broker must send a content header frame with an extreme declared body Size. The AT:P attack requirement means this is a broker-attacks-its-clients threat model, not exploitation by an arbitrary unauthenticated network attacker - the primary limiting factor is that the victim must be talking to an untrusted or subverted broker. No special client configuration is needed; the flaw affects default behavior because the preallocation was never capped to the negotiated Connection.Config.FrameSize (note: a FrameSize of 0 means unlimited, which removes the cap entirely even after the fix).

This is a client-side denial-of-service in the official RabbitMQ Go AMQP 0.9.1 client library, not a server-side or arbitrary-code flaw. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H = 8.9 High) correctly captures that the only impact is availability (VC:N/VI:N) via memory exhaustion, and importantly includes AT:P - an attack requirement - reflecting that exploitation depends on the client connecting to a malicious or compromised broker rather than any arbitrary internet attacker. The 8.9 score appears inflated: SA:H (subsequent-system availability) double-counts what is really a single-process crash of the vulnerable client itself, and the AT:P broker-trust precondition materially limits real-world reach, since a broker that is already malicious/compromised can typically disrupt or lie to its clients through many other means. There is no CISA KEV listing, no public exploit code identified, and no EPSS score in the provided data, so there is no evidence of exploitation - this is a code-quality/robustness fix, not an urgent externally-driven threat. The provided vector is CVSS 4.0 only; no CVSS 3.1 vector was supplied. Realistic priority is moderate-to-low: patch as part of normal dependency hygiene, prioritizing services that connect to brokers outside your trust boundary (multi-tenant, third-party, or internet-exposed brokers).

An attacker who controls or has compromised an AMQP broker (or performs an active man-in-the-middle on an unauthenticated/untrusted broker connection) sends a content header frame declaring an extreme uint64 body size. The amqp091-go client (<1.13.0) calls recvContent and preallocates a byte slice of that declared size before any body data arrives, forcing the Go runtime into a huge allocation that exhausts memory and terminates the client process. No public exploit code is identified, and exploitation requires the victim to be connected to an attacker-influenced broker (AT:P).