CVE-2026-61634

Overview

The RabbitMQ Java Client is the RabbitMQ team's AMQP 0.9.1 client library, which allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. It is published to Maven Central as com.rabbitmq:amqp-client, and Spring AMQP applications, including Spring Boot ones, use it through spring-rabbit's CachingConnectionFactory.

A denial of service vulnerability (CVE-2026-61634) has been identified in the RabbitMQ Java Client's inbound frame readers, which allows a malicious or compromised broker to send frames larger than the frame_max negotiated during connection tuning. The client allocates and decodes these protocol-invalid frames instead of rejecting them, which can disrupt the affected connection and cause client-side denial of service.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

This issue affects all versions of the RabbitMQ Java Client prior to 5.33.0.

Details

Module Info

• Product: RabbitMQ Java Client
• Affected packages: com.rabbitmq:amqp-client
• Affected versions: <5.33.0
• GitHub repository: https://github.com/rabbitmq/rabbitmq-java-client
• Published packages: https://central.sonatype.com/artifact/com.rabbitmq/amqp-client
• Package manager: Maven
• Fixed in:
  • OSS RabbitMQ Java Client 5.33.0
  • NES for RabbitMQ Java Client v5.24.2

Vulnerability Info

This Low-severity vulnerability is found in the com.rabbitmq:amqp-client package in all versions of the RabbitMQ Java Client prior to 5.33.0.

During the AMQP 0.9.1 handshake, the broker sends connection.tune and the client negotiates a maximum frame size, frame_max. In AMQConnection.start() the negotiated value is only stored and echoed back in connection.tune-ok; it is never passed to the frame handler that reads inbound frames:

int frameMax =
    negotiatedMaxValue(this.requestedFrameMax,
                       connTune.getFrameMax());
this._frameMax = frameMax;

The blocking socket reader, SocketFrameHandler.readFrame(), calls Frame.readFrom(_inputStream, this.maxInboundMessageBodySize). maxInboundMessageBodySize is the limit on whole message bodies, 64 MiB by default, and it is the only bound Frame.readFrom applies to the broker-supplied payload length before allocating and filling the payload buffer:

channel = is.readUnsignedShort();
int payloadSize = is.readInt();
if (payloadSize >= maxPayloadSize) {
    throw new IllegalStateException(format(
        "Frame body is too large (%d), maximum configured size is %d. " +
            "See ConnectionFactory#setMaxInboundMessageBodySize " +
            "if you need to increase the limit.",
        payloadSize, maxPayloadSize
    ));
}
byte[] payload = new byte[payloadSize];
is.readFully(payload);

The NIO reader, com.rabbitmq.client.impl.nio.FrameBuilder, applies the same framePayloadSize >= maxPayloadSize check against the same value. A broker peer can therefore send a method frame whose payload exceeds the negotiated frame_max, during or after connection establishment, and the client allocates a buffer of up to the message body limit for each such frame and decodes it instead of rejecting it as a protocol violation. A malicious or compromised broker can use this to make the client hold far more memory per frame than the connection agreed to, and the protocol violation can disrupt the affected connection.

Mitigation

The RabbitMQ team lists the AMQP 0.9.1 Java Client 5.x series as currently supported and ships fixes in new 5.x releases. Upstream has made no 5.24.x release since 5.24.0 (December 2024), so no 5.24.x release is available to address this issue. For more information, see here.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to a release of the RabbitMQ Java Client 5.x series that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Alexender676 from Team Atlanta (finder)