RabbitMQ Java Client CVE-2026-63335

Exploitation requires the RabbitMQ Java client to have an open, active AMQP connection to a broker that the attacker controls or has compromised - the malformed frame must originate from the broker side of the connection, not from the Java application or an arbitrary third party. The malformed sequence must be sent on a non-zero (active) channel; channel 0 (the connection control channel) is handled separately and does not route through the vulnerable CommandAssembler path for content-bearing frames. The attack is therefore limited to three scenarios: (1) the broker itself is malicious or fully compromised at the process level, (2) a man-in-the-middle can inject raw AMQP frames on an unencrypted AMQP connection (port 5672), or (3) a client misconfiguration routes traffic to a rogue broker. Connections using TLS with strict server certificate validation substantially limit scenario 2. No default configuration of the Java client prevents this attack once a connection is established to a hostile broker. The setMaxInboundMessageBodySize parameter does not serve as a compensating control because the vulnerability lies in the ordering of subtraction versus validation within consumeBodyFrame.

The CVSS 4.0 score of 6.3 (Medium) with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H correctly frames the impact: the vulnerable system (the library itself) suffers no direct confidentiality or integrity loss, but the subsequent system - the Java application relying on the connection - loses high availability when its connection is forcibly torn down. PR:L reflects that exploitation requires an established, authenticated AMQP connection to a broker the attacker controls or has compromised, meaningfully limiting the attack surface compared to unauthenticated network attacks. No EPSS score was provided for independent comparison. The absence of a CISA KEV entry indicates no confirmed active exploitation at time of analysis, though a PoC is referenced in the GHSA advisory (poc.zip), which lowers the barrier for opportunistic testing. The realistic threat actors are: a supply-chain-compromised or insider-controlled RabbitMQ broker, a rogue broker reachable due to misconfiguration, or a man-in-the-middle on unencrypted AMQP connections. Organizations whose Java clients connect exclusively to internally managed, trusted brokers face low practical risk; those routing clients through shared, external, or cloud-managed brokers face meaningfully higher exposure.

An attacker who controls a rogue RabbitMQ broker (or has compromised a legitimate one) waits for a Java application to establish a connection and open a channel. Once a non-zero channel is active, the broker sends a Basic.Deliver method frame followed by a content header declaring exactly 1 byte of body, then immediately sends a body frame containing 2 bytes. CommandAssembler subtracts 2 from remainingBodyBytes (value 1), driving it to -1, hits the UnsupportedOperationException stub, and AMQConnection shuts down the entire connection, terminating all in-flight work. A PoC demonstrating this three-frame sequence is referenced in the GHSA advisory (poc.zip).