CVE-2026-69219 in Java Client
Summary
by MITRE • 08/18/2026
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.33.1, src/main/java/com/rabbitmq/client/impl/ValueReader.java uses ValueReader.readBytes to accept a wire-declared contentLength below Integer.MAX_VALUE and allocate a byte array before checking the bytes available in the frame. A malicious 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, causing an approximately 2 GB allocation and OutOfMemoryError before readFully consumes data. The resulting memory exhaustion can terminate the JVM and cause denial of service. This issue is fixed in version 5.33.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/18/2026
The RabbitMQ Java client library serves as a critical component for enabling Java and JVM-based applications to establish connections with RabbitMQ message broker nodes, facilitating reliable asynchronous communication within distributed systems. A significant vulnerability was identified in the handling of AMQP protocol frames prior version 5.33.1, specifically within the ValueReader class located at src/main/java/com/rabbitmq/client/impl/ValueReader.java. This component is responsible for parsing incoming data streams from the server to ensure that client applications can correctly interpret messages and connection parameters sent by RabbitMQ nodes or other AMQP peers.
The core technical flaw lies in the sequence of operations performed when reading byte arrays during the pre-authentication phase, specifically within the connection.start handshake process where server properties are exchanged. The vulnerability arises because the ValueReader.readBytes method first allocates a Java byte array based on the contentLength declared by the remote peer before verifying whether sufficient bytes are actually available in the current frame buffer. This ordering error creates a window of opportunity for exploitation, as memory is committed to an object that may never be fully populated or used if the stream terminates prematurely due to malicious input.
A malicious AMQP peer can exploit this logic flaw by sending a LongString or byte-array field with type tag S and a declared length close to Integer.MAX_VALUE, such as 0x7FFFFFFE, which corresponds to approximately two gigabytes of memory allocation. By injecting such an oversized declaration during the initial connection setup before authentication has occurred, the attacker forces the client JVM to attempt allocating this massive block of heap space immediately upon receiving the frame header. This action triggers a severe OutOfMemoryError because the Java Virtual Machine cannot satisfy the request for contiguous memory of that magnitude under normal operating conditions or even with increased heap sizes if other resources are constrained.
The operational impact of this vulnerability is a complete denial of service against any JVM-based application utilizing the affected RabbitMQ client library version. The resulting memory exhaustion causes the JVM process to terminate abruptly, effectively disconnecting the application from the message broker and halting all dependent services that rely on real-time messaging capabilities. This represents a critical availability risk for production environments where high uptime is required, as an attacker does not need valid credentials or complex payload delivery mechanisms beyond establishing a connection and sending this specific malformed frame during startup.
This vulnerability aligns with CWE-789: Memory Allocation with Untrusted Input, which describes the failure to properly validate input data before allocating resources based on that input size. Furthermore, it maps to MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically under subtechniques involving resource exhaustion through memory consumption attacks. The attack vector is classified as Network-based with Low complexity, requiring only network connectivity and the ability to send AMQP frames during the connection handshake phase.
The issue has been remediated in RabbitMQ Java client library version 5.33.1 by correcting the order of operations within the ValueReader class. The fix ensures that available bytes are validated against the declared content length before any significant memory allocation occurs, thereby preventing the server or malicious peer from forcing excessive heap consumption through oversized declarations. Organizations running applications with older versions of this library should prioritize upgrading to version 5.33.1 or later to mitigate the risk of remote denial-of-service attacks targeting their JVM infrastructure and ensure resilience against malformed AMQP protocol inputs during connection establishment.