CVE-2026-61634: RabbitMQ Java client accepts broker frames larger than the negotiated AMQP frame_max
Summary The max body size was enforced to patch CVE-2023-46120, but even though that limit still works, the frame size itself still exceeds the given max size.
Root cause The Java client records the AMQP 0-9-1 framemax negotiated during connection tuning, but the socket inbound frame reader continues to validate broker-controlled payload lengths against the much larger maxInboundMessageBodySize limit. A broker peer can therefore send a method frame whose payload is larger than the negotiated framemax, have it allocated and decoded, and complete the connection handshake instead of being rejected as a protocol violation.
Reported by Team Atlanta.
Other sources
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.33.0, the AMQP connection tuning path records the negotiated AMQP framemax value, but src/main/java/com/rabbitmq/client/impl/SocketFrameHandler.java and NettyFrameHandlerFactory continue to validate broker-controlled frame payload lengths against maxInboundMessageBodySize because the negotiated limit is not applied consistently through setMaxInboundFramePayloadSize. A malicious or compromised broker can send a method frame larger than the negotiated framemax during or after connection establishment, causing the client to allocate and decode a protocol-invalid frame instead of rejecting it with MalformedFrameException. The protocol violation can disrupt the affected connection and cause client-side denial of service. This issue is fixed in version 5.33.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/com.rabbitmq:amqp-clientto a version that resolves this vulnerability.Fixed in 5.33.0 - Upgrade
Upgrade
RabbitMQ Java clientto a version that resolves this vulnerability.Fixed in 5.33.0
Event History
Frequently Asked Questions
Which deployments are exposed?
Applications using RabbitMQ Java client versions prior to 5.33.0 are affected when they connect to a malicious or compromised broker peer. The issue applies to Java and JVM-based applications using this client library.
What access does an attacker need to exploit this?
An attacker needs to control or compromise the broker peer that the client connects to, so it can send an oversized AMQP method frame during connection handling. The client accepts, allocates, and decodes the frame instead of rejecting it for exceeding the negotiated frame_max.
What is the remediation?
Upgrade the RabbitMQ Java client to version 5.33.0 or later. The provided information does not specify an alternative mitigation for environments that cannot upgrade immediately.