CVE-2026-67218: RabbitMQ: Super-stream HTTP creation skips configure-permission check
RabbitMQ is a messaging and streaming broker. Prior to versions 4.0.22, 4.1.11, 4.2.6, and 4.3.0, acceptcontent/2 at line 56 calls rabbitstreammanager:createsuperstream/... directly after isauthorized (which only checks the management tag + vhost access via isauthorizedvhost). The stream-protocol equivalent (rabbitstreamreader.erl createsuperstream handler) calls rabbitstreamutils:checksuperstreammanagementpermitted/4 which enforces configure on the exchange and each partition queue. The HTTP handler omits this call entirely. A user with management tag and vhost access , but no configure permission on any resource , can create super-streams (an exchange + N partition stream queues + bindings) via the HTTP API. The native stream-protocol path enforces configure on each resource; the HTTP path does not, creating a privilege escalation from 'can view' to 'can create persistent cluster-wide resources.' Preconditions include rabbitmqstreammanagement plugin enabled management tag + vhost access (no resource permissions needed). This issue is fixed in versions 4.0.22, 4.1.11, 4.2.6, and 4.3.0.
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.22 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.0
Event History
Frequently Asked Questions
Who can exploit this issue?
A user needs the management tag, access to the target virtual host, and the rabbitmq_stream_management plugin enabled. The user does not need configure permission on any resource.
What access does exploitation provide?
The affected HTTP API can let the user create a super-stream, including an exchange, partition stream queues, and bindings. This bypasses the configure-permission checks enforced by the native stream-protocol path.
Are default deployments affected?
Only deployments with the rabbitmq_stream_management plugin enabled are affected through this path. Exploitation additionally requires an account with the management tag and virtual-host access.
What can be done if upgrading is not immediately possible?
Restrict management tags and virtual-host access to trusted users, particularly where the stream management plugin is enabled. This prevents untrusted users from reaching the affected HTTP creation path.
Which versions contain the fix?
The issue is fixed in RabbitMQ 4.0.22, 4.1.11, 4.2.6, and 4.3.0.