CVE-2026-67416: 
RabbitMQ vulnerability analysis and mitigation

CVE-2026-67416 is an AMQP 1.0 symbolic body descriptor prefix collision vulnerability in RabbitMQ that allows an authenticated publisher to inject a "poison message" capable of terminating consumer protocol processes. The flaw exists in the optimized server_mode parser within deps/amqp10_common/src/amqp10_binary_parser.erl, which matches body descriptor symbols by textual prefix without verifying the encoded symbol length. Affected versions span RabbitMQ 4.0.0 through 4.0.23, 4.1.0 through 4.1.14, 4.2.0 through 4.2.9, and 4.3.0 through 4.3.3. It carries a CVSS v4.0 base score of 5.3 (Medium) (GitHub Advisory, Feedly).

The root cause (CWE-20, CWE-248, CWE-754) lies in six fast-path pattern-matching clauses in amqp10_binary_parser.erl that bind the symbol length variable _S without comparing it against the exact registered descriptor lengths (16 for amqp:data:binary, 23 for amqp:amqp-sequence:list, 17 for amqp:amqp-value:*). As a result, any described value whose descriptor merely begins with one of these registered prefixes — regardless of declared length — is misclassified as the corresponding standard body section and stored verbatim across classic, quorum, and stream queues. The primary proof-of-concept uses the well-formed but unknown descriptor amqp:data:binary@ (sym8, declared length 17): when this stored entry is later decoded during AMQP 0-9-1 cross-protocol conversion, amqp10_framing:decode_bin/1 calls record_for/1 on the unknown descriptor and exits with {unknown, {symbol, <<"amqp:data:binary@">>}}, terminating the consumer protocol process. With acknowledgement-required delivery, the undelivered message is requeued and the failure repeats on reconnection (GitHub Advisory, Fix Commit).

The primary impact is a targeted availability denial against AMQP 1.0 consumers and AMQP 0-9-1 consumer protocol processes: affected consumers terminate while decoding the stored poison message, and with acknowledgement-required delivery the failure can repeat indefinitely after reconnection. The RabbitMQ broker node itself remains alive, and the vulnerability does not bypass routing, authorization, or tenant isolation. There is no confidentiality or integrity impact — an authorized publisher can, however, disrupt consumption by another principal sharing the same queue, crossing a tenant boundary in multi-tenant deployments (GitHub Advisory).

No public exploit kit or weaponized tooling has been reported, and there is no evidence of in-the-wild exploitation as of the disclosure date. The vulnerability requires authenticated AMQP 1.0 access with write permission to a target exchange or queue, and a victim must consume the stored entry via a strict AMQP 1.0 decoder or a cross-protocol conversion path. A minimal deterministic proof-of-concept is included in the GitHub Security Advisory and can be reproduced with a standard Erlang/OTP 27 environment. The EPSS score is 0.0, and the vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Authenticate to RabbitMQ over AMQP 1.0: Obtain valid credentials with write permission to a target exchange or queue on a vulnerable RabbitMQ instance (versions 4.0.0–4.0.23, 4.1.0–4.1.14, 4.2.0–4.2.9, or 4.3.0–4.3.3).
2. Craft a poison message payload: Construct a well-formed AMQP 1.0 described value whose descriptor begins with a registered body descriptor prefix but has a non-standard declared length. The primary PoC uses amqp:data:binary@ (sym8, declared length 17):

00 a3 11 61 6d 71 70 3a 64 61 74 61 3a 62 69 6e 61 72 79 40 a0 03 61 62 63

3. Publish the payload: Send the crafted transfer payload to the target queue via AMQP 1.0. The server_mode parser misclassifies the descriptor as a standard data body section and stores the raw bytes unchanged.
4. Trigger consumer failure: Wait for a victim consumer to dequeue the stored entry. A strict AMQP 1.0 consumer will exit when its normal decoder encounters the unknown descriptor. For AMQP 0-9-1 consumers, the broker-side cross-protocol conversion calls amqp10_framing:decode_bin/1, which exits with {unknown, {symbol, <<"amqp:data:binary@">>}}, terminating the consumer protocol process.
5. Sustain the denial: With acknowledgement-required delivery, the undelivered message is requeued and the failure repeats on every reconnection attempt, causing a persistent disruption of consumer availability (GitHub Advisory).

• Logs: RabbitMQ broker logs showing repeated {unknown, {symbol, <<"amqp:data:binary@">>}} or similar Erlang exit errors originating from amqp10_framing or mc_amqp modules; consumer protocol process crash reports in rabbit.log.
• Logs: Repeated redelivery attempts for the same message on an acknowledgement-required queue, visible as escalating redelivery counts in management UI or broker logs.
• Network: AMQP 1.0 transfer frames containing a descriptor byte sequence starting with 00 a3 11 61 6d 71 70 3a 64 61 74 61 3a 62 69 6e 61 72 79 40 (sym8 amqp:data:binary@) or similar prefix-colliding descriptors.
• Process: Unexpected termination and restart of Erlang consumer protocol processes (rabbit_reader, rabbit_amqp_session) without corresponding broker node restarts (GitHub Advisory).

RabbitMQ has released patched versions that enforce exact symbol length matching in all six fast-path clauses of the server_mode parser: 4.0.24, 4.1.15, 4.2.10, and 4.3.4. The fix modifies deps/amqp10_common/src/amqp10_binary_parser.erl to require the declared symbol length to equal exactly 16 (data), 23 (sequence), or 17 (value), falling through to normal parsing otherwise. No configuration-based workaround is available; upgrading to a patched version is the only remediation. Operators should also consider implementing ingress body validation and catching parser exits at protocol conversion boundaries as defense-in-depth measures (GitHub Advisory, Fix PR, Fix Commit).

The vulnerability was reported by researcher kjsxz and the advisory was published by RabbitMQ maintainer michaelklishin on July 23, 2026. The fix was reviewed and merged the same day by maintainer lhoguin, reflecting a rapid response from the RabbitMQ team. The NixOS security tracker also flagged the issue for downstream packaging updates (GitHub Advisory, Fix PR).