CVE-2026-69220: 
Java vulnerability analysis and mitigation

CVE-2026-69220 is an uncontrolled recursion vulnerability in the RabbitMQ Java client library (com.rabbitmq:amqp-client) that allows a malicious or compromised AMQP server (or network intermediary) to trigger a StackOverflowError, causing denial of service. It affects all versions of rabbitmq-java-client up to and including 5.33.0, and was disclosed on August 18, 2026, with a fix released in version 5.33.1. The vulnerability was reported by researcher lucianjohnhouse and published via GitHub Security Advisory GHSA-93j5-89vc-pph4. It carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory).

The root cause is CWE-674 (Uncontrolled Recursion) in src/main/java/com/rabbitmq/client/impl/ValueReader.java. The methods readTable() and readArray() mutually recurse through readFieldValue() when encountering AMQP field types F (table) and A (array), with no depth limit enforced. An attacker controlling an AMQP server or acting as a man-in-the-middle can craft a connection.start frame containing approximately 580 levels of nested tables — each level consuming roughly 7 bytes (4-byte length + 1-byte key length + 1-byte key + 1-byte type tag), totaling ~4,060 bytes well within the default 131,072-byte frame maximum. With a default JVM stack of ~512KB (~864 bytes per frame), this depth is sufficient to trigger a StackOverflowError that kills the client I/O thread. The vulnerability is exploitable pre-authentication, as connection.start is the very first frame sent by the server (GitHub Advisory, Fix PR #2007).

Successful exploitation results in a denial of service: the StackOverflowError terminates the client's I/O processing thread, rendering the RabbitMQ Java client unable to communicate with any broker. There is no impact on confidentiality or integrity — the vulnerability is purely an availability issue. Because the attack is exploitable before authentication completes, any Java or JVM-based application using the affected client library and connecting to an untrusted or compromised AMQP endpoint is at risk (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Feedly). The NVD SSVC assessment classifies exploitation as "none" currently, though the attack is rated "automatable" due to its network-accessible, pre-authentication nature requiring no privileges or user interaction. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Feedly).

1. Set up a malicious AMQP server: Deploy a custom AMQP server (or perform a man-in-the-middle attack on an existing connection) that can serve crafted connection.start frames to connecting clients.
2. Craft the malicious frame: Construct a connection.start frame containing approximately 580 levels of nested AMQP table structures (type tag F). Each nesting level requires ~7 bytes (4-byte length prefix + 1-byte key length + 1-byte key + 1-byte type tag), resulting in a payload of ~4,060 bytes — well within the 131,072-byte AMQP frame limit.
3. Wait for client connection: The vulnerable Java client initiates a TCP connection to the AMQP server. The server immediately sends the crafted connection.start frame as the first protocol message (pre-authentication).
4. Trigger StackOverflowError: The client's ValueReader.readFieldValue() → readTable() → readFieldValue() mutual recursion processes each nesting level, exhausting the JVM thread stack (~512KB default) at ~580 levels and throwing a StackOverflowError.
5. Achieve denial of service: The StackOverflowError terminates the client's I/O processing thread, causing the application to lose its AMQP connection and become unable to reconnect or process messages (GitHub Advisory, Fix Commit).

• Logs: Java application logs showing java.lang.StackOverflowError originating from com.rabbitmq.client.impl.ValueReader.readFieldValue, readTable, or readArray stack frames; sudden loss of AMQP connection during the handshake phase (before authentication completes).
• Network: Unexpected or unauthorized AMQP server endpoints (port 5672/5671) in network traffic; connection.start frames from unknown or untrusted IP addresses with unusually large or deeply structured table payloads.
• Process: JVM thread dumps showing a thread stuck in deep recursive calls within com.rabbitmq.client.impl.ValueReader; application threads blocked or terminated unexpectedly during broker connection establishment.

The primary remediation is to upgrade the RabbitMQ Java client (com.rabbitmq:amqp-client) to version 5.33.1 or later, which enforces a maximum nesting depth of 32 levels and throws MalformedFrameException when exceeded (GitHub Advisory, Fix PR #2007). As a network-level workaround, restrict client connections to only trusted, known-good AMQP brokers and use TLS mutual authentication to prevent man-in-the-middle scenarios. Implementing connection validation or a network proxy that filters AMQP frames with excessive nesting depth can also reduce exposure until patching is possible.