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
- Attacker initiates a connection to the RabbitMQ Java client as a malicious AMQP server.
- The client initiates the standard AMQP
Connection.Tunehandshake negotiation. - The attacker sends a
Connection.Tuneresponse with theframeMaxfield set to 0. - The client's
AMQConnectionlogic incorrectly evaluates the limit as 0 instead of falling back to the configuredmaxInboundMessageBodySize. - The client sets the effective frame payload limit to
Integer.MAX_VALUEdue to the misinterpretation of 0-means-unlimited. - The attacker sends a frame (method, header, or body) with a manipulated size field set to a very large value (e.g., 0x1FFFFFFF).
- The client executes
new byte[frameSize]insideFrame.readFrom()based on the attacker's supplied size. - 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
Mitigations
Patch library dependency
CVE-2026-75516