CVE-2026-69220

If you run the RabbitMQ Java client library in any deployment where the broker is not fully trusted—or where network intermediaries could inject malicious data—you need to address CVE-2026-69220 immediately. The vulnerability is a stack overflow in the AMQP table and array parser. Version 5.33.0 processes recursively nested structures without any depth limit, and a payload of approximately 580 levels of nesting (well within standard frame sizes) triggers the overflow during the connection handshake, before any authentication occurs. The root cause is straightforward: the client library was designed with an implicit assumption that the broker is a trusted peer, so the parser implements the 'natural' recursive descent approach without defensive depth limiting. This assumption is no longer safe. Modern deployments include broker federation, proxies, and message routing where clients may connect to endpoints that have not authenticated their upstream. A single compromised or malicious broker can simultaneously DOS every client connecting to it, pre-authentication, with a payload indistinguishable from legitimate traffic. Verify you are running version 5.33.1 or later, which adds depth limiting to ValueReader.readFieldValue. However, the patch is only the immediate fix. Audit any other protocol clients or parsers in your codebase for the same pattern: recursive descent parsers handling untrusted input without depth guards. This is the same vulnerability class that has appeared in XML parsers (billion laughs), YAML parsers, and JSON parsers—each time with the same post-mortem conclusion and the same subsequent forgetting. The deployment reality matters as much as the code fix. Maven Central still hosts the vulnerable version without warning labels. Docker images and pinned dependency configurations may contain 5.33.0 indefinitely. The window between disclosure and full ecosystem remediation creates an asymmetry: attackers already know the trigger condition, while defenders must manually coordinate updates across independent deployment pipelines. Treat this as a structural exposure with a compounding remediation lag, not a single-patch event.

Reviewed through automated stages and approved by a human before publication.