GHSA-6c5v-hqjr-5xxp amqp091-go has a Potential Memory Exhaustion/Protocol Violation via Broker-Controlled Oversized Payload

• Go github.com/rabbitmq/amqp091-go: < 1.13.0 → fixed in 1.13.0

Summary A vulnerability exists in the amqp091-go client library where a compromised or malicious AMQP broker can force the client to allocate resources for and process content body frames that exceed the negotiated frame_max limit. This can lead to unexpected memory consumption or application-layer denial of service (DoS), bypassing the protocol's built-in framing constraints. Details During a standard AMQP 0-9-1 connection handshake, the client and the broker negotiate a maximum frame size (frame_max), for example, 4096 bytes. However, after negotiation, a malicious broker can send a valid basic.deliver sequence containing a content body frame whose header declares a payload size larger than the negotiated frame_max. Instead of enforcing the agreed-upon limit and closing the connection with a frame-error (as mandated by the AMQP 0-9-1 specification), the amqp091-go client: 1. Accepts the broker-declared oversized frame size. 2. Allocates memory based on this oversized declaration. 3. Reads the payload, assembles it into the message, and delivers it to the consumer. Impact • Denial of Service (DoS): If a broker sends extremely large frame sizes, it can trigger significant memory allocations on the client side, potentially leading to Out-Of-Memory (OOM) crashes. • Protocol Violation: The client fails to enforce negotiated connection parameters, trusting the broker implicitly even after constraints have been established.