CVE-2026-75516 in RabbitMQ
Summary
by MITRE • 09/17/2026
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.34.0, AMQConnection.start() applies Math.min(maxInboundMessageBodySize, frameMax) after Connection.Tune negotiation even though AMQP defines frameMax value zero as unlimited and ConnectionFactory.DEFAULT_FRAME_MAX is zero. When the client default and server-negotiated value are both zero, the result is passed to Utils.framePayloadLimit(int), which interprets zero as Integer.MAX_VALUE and disables the configured maxInboundMessageBodySize cap. A malicious AMQP server, or a man-in-the-middle attacker able to modify Connection.Tune and inject frames into the connection, can then send an oversized frame of any frame type, causing Frame.readFrom() to allocate a large byte array before content-level validation and potentially terminate the client process through memory exhaustion. This issue is fixed in version 5.34.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The RabbitMQ Java client library serves as a critical interface for Java and JVM-based applications to communicate with RabbitMQ message brokers, facilitating reliable asynchronous messaging across distributed systems. A significant security vulnerability exists within the connection initialization logic of this library, specifically in how it handles frame size limits during the AMQP protocol negotiation phase. The flaw resides in the implementation of the AMQConnection.start() method, which is responsible for establishing the initial parameters of an AMQP session between the client and the server. This function applies a mathematical minimum operation to determine the maximum inbound message body size by comparing the configured maxInboundMessageBodySize against the frameMax value negotiated during Connection.Tune negotiation. The underlying assumption in this logic was that both values would result in a positive integer limit, but it fails to account for specific edge cases defined within the AMQP 0-9-1 specification where zero represents an unlimited size rather than a numeric cap.
The technical root cause of this vulnerability stems from a misinterpretation of protocol semantics regarding frame limits. According to the Advanced Message Queuing Protocol standard, a frameMax value of zero indicates that there is no limit on frame sizes. However, the RabbitMQ Java client library defaults its ConnectionFactory.DEFAULT_FRAME_MAX setting to zero. When both the client's default configuration and the server-negotiated value are zero, the Math.min operation yields zero as the result. This zero value is subsequently passed to Utils.framePayloadLimit(int), a utility function that incorrectly interprets an input of zero as Integer.MAX_VALUE rather than recognizing it as unlimited or applying a sensible default cap. Consequently, the configured maxInboundMessageBodySize restriction is effectively bypassed because the resulting limit becomes excessively large, allowing frames far exceeding typical memory constraints to be processed without immediate rejection at the protocol level.
The operational impact of this flaw allows for severe denial-of-service attacks through resource exhaustion. A malicious AMQP server or a man-in-the-middle attacker capable of intercepting and modifying Connection.Tune parameters can exploit this logic by negotiating a frameMax value that results in zero after the client's internal calculations. Once this condition is met, the attacker can send oversized frames of any type to the vulnerable client application. Upon receiving such a frame, the client invokes Frame.readFrom(), which attempts to allocate a byte array based on the inflated limit derived from Integer.MAX_VALUE before performing content-level validation or size checks against actual message constraints. This premature allocation consumes substantial amounts of heap memory, potentially leading to OutOfMemoryError exceptions that terminate the Java process entirely. The attack does not require code execution privileges but relies solely on network access and protocol manipulation capabilities during connection establishment.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, as well as CWE-20 regarding improper input validation where external data is accepted without adequate verification of its validity or bounds. From an ATT&CK perspective, this flaw facilitates the T1498 network denial of service technique by enabling attackers to disrupt availability through memory exhaustion rather than exploiting logic flaws for privilege escalation or data exfiltration. The severity lies in the fact that it targets a foundational component of enterprise messaging infrastructure, potentially affecting any Java-based microservice or application relying on RabbitMQ for asynchronous communication patterns.
Mitigation strategies primarily involve upgrading the RabbitMQ Java client library to version 5.34.0 or later, where this logic has been corrected to properly handle zero values and enforce reasonable default limits even when protocol negotiation suggests unlimited capacity. Organizations should also implement network-level controls such as firewalls or intrusion detection systems that monitor for unusually large AMQP frames during connection setup phases. Additionally, application developers can configure explicit frame size limits in their ConnectionFactory settings rather than relying on defaults to ensure consistent behavior regardless of server-side negotiations. Regular patch management and dependency scanning are essential to maintain the integrity of messaging infrastructure against such protocol-level abuse vectors.