amqp091-go EUVD-2026-95161

Requires the vulnerable client (amqp091-go 1.13.0 through pre-1.14.0) to initiate a connection via the public Open function to an AMQP peer that is attacker-controlled, compromised, or MITM'd - the malicious server sends a body-frame header with an oversized declared payload length during the handshake. The flaw is reachable even when Config.FrameSize is set to the protocol minimum, and it triggers before connection.tune negotiation and before authentication complete, so client credentials and broker-side auth do not limit it. LIMITING FACTOR: the attacker must occupy the broker/peer role (no exploitation by arbitrary off-path network attackers), so clients that only connect to trusted, controlled brokers are not realistically exposed; impact is confined to availability of the client process (OOM/crash), with no data exposure or code execution.

Overall a MEDIUM real-world risk. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 6.3 and is self-consistent with the description: the only impact is availability (VA:L), with no confidentiality or integrity effect, i.e. this is a pure denial-of-service / uncontrolled-resource-allocation flaw (CWE-770). The key differentiator is AT:P (attack requirement present): exploitation is not opportunistic against arbitrary internet hosts - the attacker must BE the AMQP peer the client connects to, i.e. operate a rogue/malicious broker, compromise a legitimate one, or MITM the connection. No EPSS score was provided (exploitation probability unknown), the CVE is NOT in CISA KEV (no confirmed active exploitation), and no public exploit code was identified - the only source-code artifact supplied is the fix PR #377, not a weaponized POC. Signals are therefore consistent rather than conflicting: a medium-CVSS DoS with a meaningful trust-boundary precondition and no evidence of exploitation. Realistic priority is elevated for Go services that connect to untrusted, third-party, or multi-tenant brokers (the pre-authentication trigger means credentials/TLS client auth do NOT mitigate it), and lower for deployments where clients only ever reach a trusted, controlled internal broker. Note the vulnerable window is before connection.tune and before authentication, so this is not gated by valid credentials.

An attacker who runs a malicious AMQP broker, has compromised a legitimate one, or can MITM the connection waits for a vulnerable Go service using amqp091-go 1.13.x to connect via the public Open API. During the handshake - before connection.tune negotiation and before authentication complete - the server returns a short body-frame header declaring a very large payload length, causing the client to pre-allocate attacker-chosen memory and crash via out-of-memory. No public exploit code is known; the fix PR #377 documents the vulnerable allocation path.