CVE-2026-67241: RabbitMQ: AMQP 1.0 management exchange.declare skips alternate-exchange permission check
RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.9 and 4.3.3, AMQP 1.0 management exchange.declare skips alternate-exchange permission check. pUT /exchanges/:name (lines 192-240) checks only configure on the declared exchange and passes XArgs straight to rabbitexchange:declare/7. It omits the checkreadpermitted(X) + checkwritepermitted(AE) that rabbitchannel.erl:2540-2548 enforces for the alternate-exchange argument on the AMQP 0-9-1 path. The same file already implements the analogous DLX check for queues (lines 708-719), confirming this is a missing-check bug rather than intentional A user with only configure on exchange X can route X's unroutable messages into an alternate exchange they have no write permission AMQP 1.0 enabled (default in RabbitMQ 4.x) Attacker has configure on at least one exchange but lacks write on the target. This issue is fixed in versions 4.2.9 and 4.3.3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.9 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.3
Event History
Frequently Asked Questions
Who can exploit this issue?
A user needs configure permission on at least one exchange and must lack write permission on the alternate exchange they choose as the target. The issue affects the AMQP 1.0 management exchange.declare path.
Are default RabbitMQ deployments exposed?
AMQP 1.0 is enabled by default in RabbitMQ 4.x. Exposure still depends on having a user that can configure an exchange but does not have write permission on a potential alternate exchange target.
What can an attacker do with the missing permission check?
They can declare or configure an exchange so that its unroutable messages are routed to an alternate exchange for which they do not have write permission.
Which versions should be remediated?
The issue affects RabbitMQ from 4.2.0 through 4.2.8, and version 4.3.2. It is fixed in 4.2.9 and 4.3.3.