RabbitMQ Java Client EUVD-2026-80941

Exploitation requires the attacker to be either the AMQP server the client connects to (a malicious/rogue broker) or an active man-in-the-middle on the AMQP connection who can alter the Connection.Tune frame and inject frames. The vulnerable state arises with DEFAULT configuration: when both the client's ConnectionFactory.DEFAULT_FRAME_MAX (0) and the server-negotiated frameMax are 0, the maxInboundMessageBodySize cap is silently disabled. LIMITING FACTORS: the victim must initiate an outbound AMQP connection to attacker-influenced infrastructure or the attacker must hold an in-path network position (TLS, if enforced and validated, would blunt the MITM path); there is no way to trigger this against a passive, correctly-connected client, and impact is limited to crashing the client process (no code execution, no data exposure). Affected: rabbitmq-java-client prior to 5.34.0.

The vendor scores this 8.7 (CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) as a pure availability DoS (CWE-770 unbounded allocation), and the impact is real - an oversized frame causes Frame.readFrom() to allocate a large byte array before validation, terminating the JVM client via memory exhaustion. However, this is a CLIENT-library flaw, not a listening-service flaw: exploitation requires the victim application to connect to a malicious/rogue AMQP server, OR an active man-in-the-middle able to modify the Connection.Tune frame and inject frames. That threat model makes AT:N and the 'network, no-requirements' framing optimistic - a MITM position or the ability to redirect a client to an attacker broker is a meaningful precondition, so realistic difficulty is closer to AC:H/AT:P and my adjusted severity is nearer 7.x than 8.7. No EPSS, KEV, or SSVC data is provided, and no public POC is identified - only the fix PRs/commits and a GHSA advisory. Signals are consistent (confirmed patch, clear root cause in code) but point to a targeted MITM/rogue-broker scenario rather than mass exploitation. Impact is confined to availability; there is no confidentiality or integrity exposure (VC:N/VI:N).

An attacker who controls an AMQP endpoint the client connects to (a rogue broker), or who sits in-path on the AMQP connection, negotiates a frameMax of 0 in Connection.Tune (the client and server defaults) so the client's maxInboundMessageBodySize cap is disabled. The attacker then sends a single oversized frame of any type, forcing Frame.readFrom() to pre-allocate a huge byte array and crash the JVM through memory exhaustion. No public exploit code is identified, but the fix commits and a detailed regression test (InboundFrameMax) publicly demonstrate the trigger conditions.