~ / search / GHSA-6c5v-hqjr-5xxp

GHSA-6c5v-hqjr-5xxp

amqp091-go has a Potential Memory Exhaustion/Protocol Violation via Broker-Controlled Oversized Payload

Source: GitHub Advisory Database (reviewed) High CVE-2026-79921

Packages

EcosystemPackageAffectedFixed in
Go github.com/rabbitmq/amqp091-go < 1.13.0 1.13.0

Details

As written in the advisory (Markdown source, shown as plain text).

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

References

External links from the advisory. They lead to third-party sites.