CVE-2026-67416: RabbitMQ: AMQP 1.0 symbolic body descriptor prefix collisions bypass validation
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.24, 4.1.15, 4.2.10, and 4.3.4, the optimized AMQP 1.0 servermode parser in deps/amqp10common/src/amqp10binaryparser.erl matches the textual prefixes of symbolic data, sequence, and value body descriptors without verifying their encoded symbol lengths. An authenticated AMQP 1.0 publisher with write permission can submit a well-formed unknown descriptor that begins with a registered body descriptor, and RabbitMQ misclassifies and stores the bytes as a standard body section. Strict AMQP 1.0 consumers can terminate while decoding the stored entry. For bodies misclassified as data, AMQP 0-9-1 or other cross-protocol conversion performs full body decoding and can terminate the consumer protocol process, with acknowledgement-required delivery permitting repeated failures. Sequence and value classifications are normally transported as opaque encoded payloads on that conversion path. The broker remains alive, and the issue does not bypass routing or authorization. This issue is fixed in versions 4.0.24, 4.1.15, 4.2.10, and 4.3.4.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.24 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.10 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.4
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated AMQP 1.0 publisher that has write permission to a target can submit the crafted message. The issue does not bypass RabbitMQ routing or authorization controls.
Which consumers are most likely to be disrupted?
Strict AMQP 1.0 consumers can terminate when decoding a stored message with a misclassified body descriptor. AMQP 0-9-1 and other cross-protocol consumers can also have their consumer protocol process terminate when the body is misclassified as data, because that path fully decodes the body.
Can this cause a broker-wide outage or repeated consumer failures?
The broker remains alive, but affected consumer processes can terminate. When acknowledgement is required for delivery, the same message can be redelivered and cause repeated failures.
What should be done if upgrading cannot happen immediately?
Limit AMQP 1.0 publishing access to trusted principals with write permission, particularly for queues or routes consumed through AMQP 0-9-1 or other protocol-conversion paths. Review unacknowledged or repeatedly redelivered messages if consumers are terminating during message decoding.
Which versions contain the fix?
The issue is fixed in RabbitMQ 4.0.24, 4.1.15, 4.2.10, and 4.3.4.