Skip to content
Threat Feed
medium advisory

RabbitMQ Java Client Out-of-Memory Vulnerability via Frame Negotiation

A logic error in the RabbitMQ Java client's frame size negotiation allows a malicious server to trigger a massive memory allocation and service crash by exploiting an integer comparison flaw in frame handling.

CVE search metadata

CVE search record: CVE-2026-75516. KEV: no. Product: amqp-client (< 5.34.0). Brief: RabbitMQ Java Client Out-of-Memory Vulnerability via Frame Negotiation. Brief link: https://feed.craftedsignal.io/briefs/2026-09-rabbitmq-frame-oom/

The RabbitMQ Java client library (com.rabbitmq:amqp-client) is vulnerable to an Out-Of-Memory (OOM) denial-of-service condition due to a logic flaw in how it negotiates the maximum frame size (frameMax) with an AMQP server. When an AMQP server or an adversary in a Man-in-the-Middle (MITM) position sends a Connection.Tune handshake with frameMax=0 (signifying unlimited size per the AMQP specification), the client incorrectly executes Math.min(maxInboundMessageBodySize, 0). This operation results in a value of zero, which the internal Utils.framePayloadLimit function interprets as a request for Integer.MAX_VALUE. Consequently, the client's existing frame size protections are bypassed, and a single crafted frame with a large size field forces the JVM to attempt an allocation of approximately 2GB, causing the process to crash. This affects all clients using versions prior to 5.34.0.

Attack Chain

  1. Attacker initiates a connection to the RabbitMQ Java client as a malicious AMQP server.
  2. The client initiates the standard AMQP Connection.Tune handshake negotiation.
  3. The attacker sends a Connection.Tune response with the frameMax field set to 0.
  4. The client's AMQConnection logic incorrectly evaluates the limit as 0 instead of falling back to the configured maxInboundMessageBodySize.
  5. The client sets the effective frame payload limit to Integer.MAX_VALUE due to the misinterpretation of 0-means-unlimited.
  6. The attacker sends a frame (method, header, or body) with a manipulated size field set to a very large value (e.g., 0x1FFFFFFF).
  7. The client executes new byte[frameSize] inside Frame.readFrom() based on the attacker's supplied size.
  8. The JVM exhausts available heap memory, resulting in an OOM crash and denial of service for the client application.

Impact

Successful exploitation results in an immediate denial-of-service (DoS) condition on any application using the vulnerable RabbitMQ Java client. Because the crash occurs during frame processing, it is highly effective against any client connecting to a compromised or malicious AMQP broker. This impacts all sectors relying on RabbitMQ for messaging, particularly in Java-based microservices architectures where a single crashed node can disrupt downstream message processing.

Recommendation

Update the com.rabbitmq:amqp-client library to version 5.34.0 or later immediately to incorporate the corrected logic for frameMax negotiation. If patching is not immediately feasible, ensure that connections are only established to trusted brokers and inspect outbound traffic for anomalous Connection.Tune frames.


Immediate actions

Upgrade com.rabbitmq:amqp-client to 5.34.0 or later

IT Operations 48h

Mitigations

Patch library dependency

immediate Application Security

CVE-2026-75516