CVE-2026-61634: RabbitMQ Java Client DOS Vulnerability

CVE-2026-61634 Overview

CVE-2026-61634 is an input validation flaw [CWE-20] in the RabbitMQ Java client library. Prior to version 5.33.0, the client fails to consistently apply the negotiated Advanced Message Queuing Protocol (AMQP) frame_max limit to inbound frames. The connection tuning path records the negotiated value, but SocketFrameHandler.java and NettyFrameHandlerFactory continue to validate broker-controlled frame payload lengths against maxInboundMessageBodySize instead. A malicious or compromised broker can transmit a method frame larger than the negotiated frame_max, forcing the client to allocate and decode a protocol-invalid frame rather than rejecting it with MalformedFrameException. The result is disrupted connections and client-side denial of service.

Critical Impact
A malicious or compromised RabbitMQ broker can trigger client-side denial of service by sending oversized AMQP method frames that bypass the negotiated frame_max limit.

Affected Products

RabbitMQ Java client library versions prior to 5.33.0
Java and JVM-based applications using SocketFrameHandler for AMQP connections
Applications using NettyFrameHandlerFactory for Netty-based AMQP transport

Discovery Timeline

2026-08-18 - CVE-2026-61634 published to the National Vulnerability Database (NVD)
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-61634

Vulnerability Analysis

The RabbitMQ Java client negotiates a maximum AMQP frame size (frame_max) with the broker during connection establishment. This value bounds the size of frames the client will accept. The vulnerable code paths in src/main/java/com/rabbitmq/client/impl/SocketFrameHandler.java and the Netty-based NettyFrameHandlerFactory never propagate the negotiated limit into the frame reader. Instead, they validate inbound frame payload lengths only against maxInboundMessageBodySize, a static client-side ceiling.

Because the negotiated frame_max is not applied through setMaxInboundFramePayloadSize, the client accepts frames that exceed the protocol-agreed size. When such an oversized method frame arrives, the reader allocates buffers and attempts to decode content that violates the AMQP protocol contract instead of raising MalformedFrameException and closing the connection cleanly.

Root Cause

The root cause is inconsistent enforcement of a negotiated protocol parameter [CWE-20]. The AMQConnection implementation stores _frameMax after tuning but omits the call that pushes that limit into the frame handler. As a consequence, the frame reader continues to treat the broker as trusted for payload sizing.

Attack Vector

Exploitation requires an attacker-controlled or compromised broker. During or after connection tuning, the broker sends a method frame whose payload exceeds the negotiated frame_max. The client accepts and decodes the invalid frame, which corrupts protocol state and terminates the affected connection. Repeated abuse disrupts messaging availability for the client application.

java

// Patch: src/main/java/com/rabbitmq/client/impl/AMQConnection.java
//                                    connTune.getFrameMax());
            this._frameMax = frameMax;

+            // Bound inbound frames to the negotiated frame_max. EMPTY_FRAME_SIZE is
+            // the per-frame overhead; +1 because the reader rejects payloads >= the limit.
+            if (frameMax > 0) {
+                _frameHandler.setMaxInboundFramePayloadSize(
+                    Math.min(this.maxInboundMessageBodySize,
+                             frameMax - AMQCommand.EMPTY_FRAME_SIZE + 1));
+            }
+
            int negotiatedHeartbeat =
                negotiatedMaxValue(this.requestedHeartbeat,
                                   connTune.getHeartbeat());

Source: RabbitMQ Java Client Commit 08790f0

java

// Patch: src/main/java/com/rabbitmq/client/impl/FrameHandler.java
+    /** Cap inbound frame payloads, applied once frame_max is negotiated. */
+    default void setMaxInboundFramePayloadSize(int maxPayloadSize) {
+
+    }
+
    /**
     * Read a {@link Frame} from the underlying data connection.
     * @return an incoming Frame, or null if there is none
     */

Source: RabbitMQ Java Client Commit b491075

The fix adds a setMaxInboundFramePayloadSize hook to the FrameHandler interface and invokes it in AMQConnection immediately after frame_max negotiation. Inbound frames are then bounded by the smaller of maxInboundMessageBodySize and the negotiated frame_max.

Detection Methods for CVE-2026-61634

Indicators of Compromise

Unexpected AMQP connection terminations on clients running RabbitMQ Java client versions below 5.33.0.
Client logs showing frame decoding errors, buffer allocation spikes, or aborted connections without a corresponding MalformedFrameException.
Repeated reconnection loops from Java services after connecting to an untrusted or newly changed broker endpoint.

Detection Strategies

Inventory Java and JVM applications and identify dependency versions of com.rabbitmq:amqp-client below 5.33.0 using Software Composition Analysis (SCA) tools.
Monitor AMQP client logs for abnormal frame handling errors, connection resets, or protocol violations correlated with a specific broker.
Alert on Java process memory spikes coincident with AMQP connection failures.

Monitoring Recommendations

Capture and inspect network traffic to RabbitMQ brokers for frames exceeding the negotiated frame_max value.
Track AMQP connection lifecycle metrics (open, close, error counts) per broker and per client version.
Aggregate application logs into a centralized platform to correlate client crashes with broker behavior.

How to Mitigate CVE-2026-61634

Immediate Actions Required

Upgrade the RabbitMQ Java client dependency to version 5.33.0 or later in all Java and JVM-based applications.
Audit broker endpoints referenced by client configurations and restrict connectivity to trusted, authenticated brokers only.
Rebuild and redeploy application artifacts to ensure the patched client library is loaded at runtime.

Patch Information

The vulnerability is fixed in RabbitMQ Java client 5.33.0. See the RabbitMQ Java Client Release v5.33.0, GitHub Security Advisory GHSA-5xwg-cfvj-gff5, and the fix pull requests (PR 1994, PR 1995) for details. The patch adds setMaxInboundFramePayloadSize and enforces the negotiated frame_max in the frame reader.

Workarounds

Restrict client connections to trusted brokers using mutual TLS and network segmentation until the upgrade is deployed.
Set a conservative maxInboundMessageBodySize on the ConnectionFactory to reduce the size of frames the client will attempt to decode.
Add supervisory logic that terminates and restarts client processes on repeated AMQP protocol errors to limit denial-of-service impact.

bash

# Maven: pin the fixed RabbitMQ Java client version
mvn versions:use-dep-version -Dincludes=com.rabbitmq:amqp-client -DdepVersion=5.33.0 -DforceVersion=true

# Gradle: update the dependency declaration
# implementation 'com.rabbitmq:amqp-client:5.33.0'

# Verify the resolved version at runtime
mvn dependency:tree | grep amqp-client