RabbitMQ Java Client CVE-2026-69220

Exploitation requires that the connecting client use the RabbitMQ Java client library (com.rabbitmq:amqp-client) at version 5.33.0 or earlier. The attacker must control, or be able to impersonate, the AMQP server that the client connects to - either by operating a malicious broker, compromising a legitimate broker, or performing a man-in-the-middle interception on an unencrypted AMQP connection. No authentication is required on the part of the attacker; exploitation occurs during the pre-authentication handshake via the connection.start frame. No special client-side configuration is needed - the vulnerable code path is exercised by the standard connection flow against any AMQP peer. Exploitation is limited by: (1) the attacker's ability to position themselves as or between the client and broker, which requires either network adjacency or the client connecting to an untrusted server; (2) mTLS enforcement, which prevents unknown intermediaries from injecting frames.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) scores 8.7, reflecting network-reachable, zero-complexity, unauthenticated exploitation with high availability impact - consistent with the technical description. EPSS data was not provided in the input and cannot be cited. KEV status is not confirmed; this is not in the CISA Known Exploited Vulnerabilities catalog at time of analysis. No standalone POC tool has been published, but the GHSA advisory provides a precise byte-level payload specification (7 bytes per nesting level, ~4,060 bytes total for a 580-level attack), which constitutes near-POC-quality disclosure. The real-world risk depends heavily on trust model: applications that connect only to known, controlled RabbitMQ brokers over private networks face minimal risk, while those connecting to third-party or multi-tenant AMQP infrastructure, or operating in environments where TLS is not enforced end-to-end, face meaningful exposure. Even a mid-sized municipal IT team in koszalin operating a shared integration platform with untrusted AMQP upstreams should treat this as an urgent upgrade given how trivially the crash payload fits within standard frame limits. The fix is available as version 5.33.1, lowering remediation cost to a dependency bump.

An attacker operating a rogue AMQP server - or positioned as a network intermediary capable of intercepting unencrypted AMQP traffic - accepts an inbound connection from a vulnerable client application. Before the client can authenticate, the attacker responds with a crafted connection.start frame containing approximately 580 levels of nested AMQP tables, totaling roughly 4,060 bytes, well within the protocol's 131,072-byte frame limit. The client's ValueReader recurses until the JVM stack overflows, raising StackOverflowError, killing the I/O thread, and rendering the client unable to process further messages or reconnect - causing denial of service to the application.