CVE-2026-69219: RabbitMQ Java Client DoS Vulnerability

CVE-2026-69219 Overview

CVE-2026-69219 is a denial-of-service vulnerability in the RabbitMQ Java client library affecting versions prior to 5.33.1. The flaw resides in src/main/java/com/rabbitmq/client/impl/ValueReader.java, where ValueReader.readBytes accepts a wire-declared contentLength below Integer.MAX_VALUE and allocates a byte array before verifying the bytes available in the frame. A malicious Advanced Message Queuing Protocol (AMQP) peer can send a LongString or byte-array field with type tag S and a declared length such as 0x7FFFFFFE during the pre-authentication connection.start server-properties table. This triggers an approximately 2 GB allocation and an OutOfMemoryError before readFully consumes any data, terminating the JVM.

Critical Impact
Unauthenticated network attackers can crash Java-based RabbitMQ clients by sending a crafted AMQP frame during the initial connection handshake, causing JVM termination and denial of service.

Affected Products

RabbitMQ Java client library versions prior to 5.33.1
Java and JVM-based applications using the RabbitMQ Java client to connect to RabbitMQ nodes
Any deployment where a client establishes AMQP connections to untrusted or attacker-controlled peers

Discovery Timeline

2026-08-18 - CVE-2026-69219 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-69219

Vulnerability Analysis

The vulnerability is a memory allocation flaw classified under CWE-789: Memory Allocation with Excessive Size Value. The RabbitMQ Java client parses AMQP wire-format field tables during connection setup. When the parser encounters a LongString field (type tag S), it reads a 32-bit length prefix and immediately allocates a byte[] of that size before validating whether the underlying frame actually contains that many bytes.

Because the allocation happens before authentication completes, any peer that can complete a TCP handshake and send a connection.start frame can trigger the flaw. A declared length of 0x7FFFFFFE (roughly 2 GB) exhausts the JVM heap and raises OutOfMemoryError, terminating the client process.

Root Cause

The root cause is missing length validation in ValueReader.readBytes. The code trusts the attacker-controlled contentLength value and allocates the buffer eagerly rather than streaming the read or bounding the length against the remaining frame size. The patch introduces validation of the declared length against available frame bytes before allocation.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker operating a malicious AMQP endpoint, or performing a man-in-the-middle attack against an unauthenticated connection path, sends a crafted server-properties table in the connection.start frame. The victim client allocates approximately 2 GB of memory and crashes.

java

// Security patch in src/main/java/com/rabbitmq/client/impl/ValueReader.java
// Validate declared length before allocating byte buffers in ValueReader
 import java.io.IOException;
 import java.math.BigDecimal;
 import java.math.BigInteger;
+import java.nio.charset.StandardCharsets;
 import java.util.Collections;
 import java.util.Date;
 import java.util.HashMap;

Source: RabbitMQ Java Client Commit 3882093

Detection Methods for CVE-2026-69219

Indicators of Compromise

JVM processes hosting RabbitMQ Java clients terminating with java.lang.OutOfMemoryError: Java heap space shortly after opening an AMQP connection
AMQP connection.start frames containing LongString fields with declared lengths approaching Integer.MAX_VALUE (for example, 0x7FFFFFFE)
Repeated client reconnect-and-crash cycles when connecting to a specific broker endpoint

Detection Strategies

Inspect AMQP traffic at the network layer for oversized LongString type tag S length prefixes in server-properties tables during the pre-authentication handshake
Correlate application logs showing OutOfMemoryError in com.rabbitmq.client.impl.ValueReader stack traces with recent outbound AMQP connections
Monitor software bills of materials (SBOMs) and dependency manifests for com.rabbitmq:amqp-client versions below 5.33.1

Monitoring Recommendations

Alert on JVM heap exhaustion events in services that maintain outbound AMQP client connections
Track connection attempts from RabbitMQ Java clients to previously unknown or non-approved broker endpoints
Instrument client hosts with resource-usage telemetry to detect abrupt multi-gigabyte allocations by AMQP client threads

How to Mitigate CVE-2026-69219

Immediate Actions Required

Upgrade the RabbitMQ Java client library to version 5.33.1 or later in all Java and JVM-based applications
Audit application dependencies and build pipelines to identify transitive uses of vulnerable amqp-client releases
Restrict outbound AMQP connections to trusted brokers using network policy or egress firewall rules

Patch Information

The issue is fixed in RabbitMQ Java client 5.33.1. Patch details are documented in GitHub Security Advisory GHSA-68mj-5wr7-6fgg, with the corresponding code changes in pull request #2007, pull request #2008, and the v5.33.1 release notes. The fix adds validation of declared field lengths in ValueReader before allocating byte buffers.

Workarounds

Enforce mutual TLS (mTLS) so clients only complete AMQP handshakes with verified, trusted brokers
Deploy network segmentation and firewall rules that block RabbitMQ Java clients from reaching untrusted AMQP endpoints
Constrain JVM heap size and enable process supervision so a crash from OutOfMemoryError results in controlled restart rather than cascading outage

bash

# Configuration example: pin the fixed version in Maven
# pom.xml dependency declaration
# <dependency>
#   <groupId>com.rabbitmq</groupId>
#   <artifactId>amqp-client</artifactId>
#   <version>5.33.1</version>
# </dependency>

# Verify installed version in a build
mvn dependency:tree | grep amqp-client