CVE-2026-75516: RabbitMQ Java Client Library DOS Vulnerability

CVE-2026-75516 Overview

CVE-2026-75516 affects the RabbitMQ Java client library, which allows Java and JVM-based applications to connect to RabbitMQ nodes over the Advanced Message Queuing Protocol (AMQP). Versions prior to 5.34.0 mishandle the frame_max value negotiated during Connection.Tune. When both the client default and server-negotiated values are zero, the client interprets the limit as Integer.MAX_VALUE, disabling the configured maxInboundMessageBodySize cap. A malicious AMQP server or man-in-the-middle attacker can send an oversized frame, forcing Frame.readFrom() to allocate a large byte array and exhaust client memory. The issue maps to [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact
A malicious or intercepted AMQP server can crash any Java client process using default configuration by transmitting a single oversized frame, resulting in denial of service through memory exhaustion.

Affected Products

RabbitMQ Java client library versions prior to 5.34.0
Java and JVM-based applications using ConnectionFactory.DEFAULT_FRAME_MAX (zero)
Applications relying on default maxInboundMessageBodySize enforcement

Discovery Timeline

2026-09-16 - CVE-2026-75516 published to NVD
2026-09-16 - Last updated in NVD database
Patch released - Fixed in RabbitMQ Java Client Release v5.34.0

Technical Details for CVE-2026-75516

Vulnerability Analysis

The vulnerability is a resource exhaustion flaw triggered by improper interpretation of the AMQP frame_max negotiation. AMQP defines a frame_max value of zero as "unlimited," and ConnectionFactory.DEFAULT_FRAME_MAX is zero. Inside AMQConnection.start(), the client calls Math.min(maxInboundMessageBodySize, frameMax) after Connection.Tune. When frameMax is zero, this returns zero. The result flows into Utils.framePayloadLimit(int), which treats zero as Integer.MAX_VALUE and effectively removes the inbound message body cap. Any attacker controlling the peer connection can then push arbitrarily large frames of any type into Frame.readFrom(), which allocates a matching byte array before content-level validation runs.

Root Cause

The root cause is inconsistent semantics for the sentinel value zero across two code paths. framePayloadLimit() correctly treats zero as unlimited, but the upstream Math.min() call in AMQConnection does not. The two functions disagree on the meaning of the negotiated value, causing the enforcement layer to silently collapse to no limit.

Attack Vector

Exploitation requires a network-adjacent attacker acting as the AMQP server or a man-in-the-middle capable of modifying Connection.Tune and injecting frames. No authentication or user interaction is required. The attacker sends an oversized frame header instructing the client to allocate memory sufficient to terminate the Java Virtual Machine (JVM) process.

java

// Security patch in src/main/java/com/rabbitmq/client/impl/Utils.java
// Honors an unlimited negotiated frame_max when capping inbound message size
static int inboundFrameMax(int maxInboundMessageBodySize, int frameMax) {
  int effectiveFrameMax = frameMax == 0 ? Integer.MAX_VALUE : frameMax;
  return Math.min(maxInboundMessageBodySize, effectiveFrameMax);
}

static int framePayloadLimit(int frameMax) {
  if (frameMax <= 0) {
    return Integer.MAX_VALUE;
// Source: https://github.com/rabbitmq/rabbitmq-java-client/commit/6d7c2bfe89796ca34d3531098fb59dd657fea39e

The patch introduces Utils.inboundFrameMax(), which explicitly maps frameMax == 0 to Integer.MAX_VALUE before performing the Math.min() comparison against maxInboundMessageBodySize. This preserves the user-configured message body cap even when the server negotiates unlimited frames.

Detection Methods for CVE-2026-75516

Indicators of Compromise

Java client processes terminating with OutOfMemoryError shortly after establishing an AMQP connection
Unexpectedly large single-frame allocations logged by JVM heap monitoring tools
AMQP Connection.Tune frames advertising frame_max of zero from untrusted or unfamiliar broker endpoints
TLS session anomalies suggesting man-in-the-middle interception between client and broker

Detection Strategies

Inventory JVM applications with RabbitMQ Java client dependencies using Software Composition Analysis (SCA) tooling and flag versions below 5.34.0
Correlate JVM crash telemetry with recent AMQP connection events to identify oversized frame allocations
Inspect broker endpoints referenced by application configuration to confirm they resolve to trusted infrastructure

Monitoring Recommendations

Instrument AMQP client processes with heap-usage metrics and alert on abrupt allocation spikes above expected message sizes
Log all Connection.Tune negotiations and flag sessions where the negotiated frame_max is zero against non-approved brokers
Enforce mutual TLS between clients and brokers and monitor certificate validation failures indicating tampering

How to Mitigate CVE-2026-75516

Immediate Actions Required

Upgrade the RabbitMQ Java client library to version 5.34.0 or later across all JVM applications
Audit ConnectionFactory configurations and set a non-zero requestedFrameMax value appropriate to application message sizes
Restrict client-to-broker communication to trusted network paths protected by TLS with certificate pinning

Patch Information

The vulnerability is fixed in RabbitMQ Java client 5.34.0. Review the RabbitMQ Security Advisory GHSA-jh4v-gfqj-7rhx, the commit 6d7c2bf, and pull request #2015 for the full fix.

Workarounds

Explicitly set ConnectionFactory.setRequestedFrameMax() to a bounded value rather than relying on the default of zero
Enforce mutual TLS with strict certificate validation to prevent man-in-the-middle injection of Connection.Tune frames
Deploy AMQP client applications behind network egress controls that restrict connections to vetted broker addresses only

bash

# Update Maven dependency to patched version
# pom.xml
# <dependency>
#   <groupId>com.rabbitmq</groupId>
#   <artifactId>amqp-client</artifactId>
#   <version>5.34.0</version>
# </dependency>
mvn versions:use-dep-version -Dincludes=com.rabbitmq:amqp-client -DdepVersion=5.34.0 -DforceVersion=true