CVE-2026-57221: Broadcom RabbitMQ Auth Bypass Vulnerability

CVE-2026-57221 Overview

CVE-2026-57221 is a missing authorization vulnerability [CWE-862] in RabbitMQ, the open-source messaging and streaming broker maintained by Broadcom. Prior to versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ skips authorization checks on passive queue.declare and exchange.declare AMQP 0-9-1 operations. Any authenticated user with access to a virtual host can enumerate queue and exchange names and read queue message and consumer counts. The issue does not permit message consumption or modification, but it discloses internal messaging topology and workload metadata to low-privileged accounts.

Critical Impact
Authenticated users on a virtual host can bypass configure-permission checks to enumerate queues, exchanges, and message counts, exposing internal broker topology.

Affected Products

Broadcom RabbitMQ Server versions prior to 3.13.15
Broadcom RabbitMQ Server 4.0.x prior to 4.0.20 and 4.1.x prior to 4.1.11
Broadcom RabbitMQ Server 4.2.x prior to 4.2.6

Discovery Timeline

2026-07-10 - CVE-2026-57221 published to NVD
2026-07-13 - Last updated in NVD database

Technical Details for CVE-2026-57221

Vulnerability Analysis

RabbitMQ implements permission classes of configure, write, and read on resources within a virtual host. When a client issues a queue.declare or exchange.declare frame with the passive flag set, the broker is expected to verify existence of the resource and return its metadata rather than create it. Prior to the patched releases, the AMQP 0-9-1 handler executed passive declarations without invoking the configure permission check. As a result, an authenticated user needed only virtual-host access to probe arbitrary queue and exchange names and receive metadata including the queue's message count and consumer count. The behavior violates the least-privilege model documented for RabbitMQ permission tags and enables reconnaissance of message-broker topology by tenants that should be restricted to a subset of resources.

Root Cause

The AMQP 0-9-1 method handlers for passive declarations in deps/rabbit/src/rabbit_channel.erl and the management path in deps/rabbit/src/rabbit_amqp_management.erl discarded the User context and did not call check_configure_permitted/3 or the equivalent check_resource_access/4 with the configure action. The absence of an authorization gate on the passive branch is the direct cause of the disclosure.

Attack Vector

Exploitation requires valid credentials and network reachability to the AMQP listener. An authenticated user connects to a virtual host and issues successive queue.declare or exchange.declare frames with passive=true, iterating candidate names. For each existing resource, the broker returns a queue.declare-ok response containing the message and consumer counts, allowing enumeration without needing any configured permission on the resource.

erlang

%% Patch: apply `configure` checks to passive queue/exchange declaration
%% File: deps/rabbit/src/rabbit_channel.erl
 handle_method(#'queue.declare'{queue   = QueueNameBin,
                                nowait  = NoWait,
                                passive = true},
-              ConnPid, _AuthzContext, _CollectorPid, VHostPath, _User) ->
+              ConnPid, AuthzContext, _CollectorPid, VHostPath, User) ->
     StrippedQueueNameBin = strip_cr_lf(QueueNameBin),
     QueueName = rabbit_misc:queue_resource(VHostPath, StrippedQueueNameBin),
+    check_configure_permitted(QueueName, User, AuthzContext),
     Fun = fun (Q0) ->
               QStat = maybe_stat(NoWait, Q0),
               {QStat, Q0}

Source: rabbitmq-server commit 709a14e

erlang

%% Patch: enforce configure check in AMQP management passive path
%% File: deps/rabbit/src/rabbit_amqp_management.erl
                 _Query,
                 null,
                 Vhost,
-                _User,
+                User,
                 _ConnPid,
-                PermCaches) ->
+                {PermCache0, TopicPermCache}) ->
     QNameBin = cow_uri:urldecode(QNameBinQuoted),
     QName = queue_resource(Vhost, QNameBin),
+    PermCache = check_resource_access(QName, configure, User, PermCache0),
+    PermCaches = {PermCache, TopicPermCache},
     case rabbit_amqqueue:with(
            QName,
            fun(Q) ->

Source: rabbitmq-server commit dc3d1aa

Detection Methods for CVE-2026-57221

Indicators of Compromise

High volumes of queue.declare or exchange.declare frames with passive=true originating from a single authenticated user or client connection.
Sequential or dictionary-style enumeration of queue and exchange names against a virtual host, particularly targeting names outside the user's normal working set.
Access log entries showing repeated access_refused errors after upgrading, indicating prior enumeration attempts now blocked by the configure check.

Detection Strategies

Enable RabbitMQ tracing on suspect virtual hosts and filter for methods queue.declare and exchange.declare with the passive bit set, correlating counts per user.
Monitor connection-level metrics for atypical channel activity from application service accounts that should only publish or consume from a fixed set of resources.
Compare application inventory of legitimate queue names against broker audit logs to identify probes for non-existent or foreign-tenant resources.

Monitoring Recommendations

Ship RabbitMQ logs and management API audit events into a centralized SIEM and alert on per-user rates of passive declare operations that exceed application baselines.
Track user session metadata including source IP, client-provided connection name, and virtual host to attribute enumeration attempts to specific credentials.
Review rabbitmqctl list_permissions output and reconcile against expected tenant boundaries so that a successful enumeration cannot be masked as legitimate configuration activity.

How to Mitigate CVE-2026-57221

Immediate Actions Required

Upgrade RabbitMQ to 3.13.15, 4.0.20, 4.1.11, or 4.2.6, matching the branch currently in use.
Rotate credentials for any accounts that may have been used to enumerate broker topology prior to patching.
Audit user permission tags with rabbitmqctl list_permissions and remove virtual-host access from accounts that do not require it.

Patch Information

Broadcom released fixes in the RabbitMQ pull requests #16085 and #16090, landed in commits 709a14e and dc3d1aa. The remediation adds configure permission checks to both the AMQP 0-9-1 channel handler and the AMQP management resource path for passive declarations. See the GitHub Security Advisory GHSA-9q2j-2hq8-22r2 and the v4.2.6 release notes for full details.

Workarounds

Restrict virtual host membership so that only trusted applications and operators hold credentials to a given vhost.
Segregate tenants by placing each on a dedicated virtual host rather than relying on per-resource configure restrictions inside a shared vhost.
Restrict network access to the AMQP listener with firewall rules or mutual TLS so that only known application hosts can authenticate.

bash

# Verify installed version and required permissions after upgrade
rabbitmqctl version
rabbitmqctl list_permissions -p /

# Example: remove a service account from a virtual host it does not need
rabbitmqctl clear_permissions -p /shared appuser

# Restrict a user to a specific queue prefix using regex-based permissions
rabbitmqctl set_permissions -p /app appuser \
  "^app\.(queues|exchanges)\..*" \
  "^app\.(queues|exchanges)\..*" \
  "^app\.(queues|exchanges)\..*"