RabbitMQ Java Client CVE-2026-69219

Exploitation requires the victim Java application to initiate an outbound AMQP connection to an endpoint controlled or compromised by the attacker, as the malicious payload is delivered server-to-client during the connection.start pre-authentication handshake - no client-side configuration change is needed. Any amqp-client version ≤ 5.33.0 is vulnerable by default when connecting to a malicious peer; the attacker does not require credentials or any established session. Key limiting factors: the attacker must control or be positioned as a man-in-the-middle on the AMQP server the client connects to; the attack direction is exclusively server-to-client and cannot be initiated by a connecting client against a server; and the impact is JVM termination (DoS), not code execution. Deployments where clients connect exclusively to internal, access-controlled RabbitMQ brokers over private networks with mutual TLS face substantially lower risk than those connecting to shared or externally managed broker infrastructure.

The CVSS 4.0 score of 8.7 with vector AV:N/AC:L/AT:N/PR:N/UI:N/VA:H accurately reflects the technical severity: remote, unauthenticated denial of service exploitable in the pre-authentication phase with no special attack prerequisites on the protocol level. However, the threat model differs from typical server-side vulnerabilities: the attacker must control or intercept the AMQP server endpoint that the victim client connects to, limiting mass-internet exploitation. Real-world risk is highest for deployments where Java applications connect to shared, cloud-hosted, or externally-managed RabbitMQ brokers that could be compromised, and lowest where brokers are fully isolated and access-controlled. KEV status is not confirmed - no CISA KEV listing appears in the available data. EPSS data is absent from the provided intelligence. No POC exploit code has been publicly released, but the GHSA advisory provides complete technical detail sufficient for trivial reimplementation. The combination of a high-severity impact (full JVM crash), pre-auth exploitation, and detailed public disclosure elevates real-world priority beyond what the absence of a KEV listing might suggest.

An attacker deploys a malicious AMQP-compatible server at a network endpoint reachable by victim Java applications and waits for a client connection. When the victim client connects, the malicious server responds to the AMQP connection.start handshake with a server-properties table containing a LongString field (type tag 0x53) with a wire-declared length of 0x7FFFFFFE. The client's ValueReader.readBytes() passes the Integer.MAX_VALUE boundary check and immediately attempts to allocate a 2,147,483,646-byte array, triggering OutOfMemoryError that crashes the entire client JVM before any authentication exchange occurs. The GHSA advisory provides the precise trigger value and vulnerable code, making implementation of an exploit server straightforward.