CVE-2026-66076 in RabbitMQ
Summary
by MITRE • 09/23/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, is_authorized/2 calls rabbit_mgmt_util:is_authorized/2, which checks only the management tag, instead of is_authorized_vhost/2. The /api/queues/quorum/:vhost/:queue/status handler reads the vhost from the path without checking that the user can access it. Any management-tagged user can therefore read Raft status, including leader, members, term, and commit index, for quorum queues in inaccessible vhosts, exposing cross-tenant queue names and cluster topology. The management plugin must be enabled and the attacker must have a management tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/23/2026
RabbitMQ serves as a widely deployed messaging and streaming broker that facilitates communication between distributed systems through message queuing protocols. A significant security vulnerability was identified in the management plugin interface prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. This flaw stems from an incorrect authorization check mechanism within the HTTP API handlers responsible for exposing cluster state information. Specifically, the function is_authorized/2 incorrectly delegates to rabbit_mgmt_util:is_authorized/2, which validates permissions based solely on whether a user possesses the management tag. It fails to invoke is_authorized_vhost/2, thereby neglecting to verify if the authenticated user has specific access rights to the virtual host referenced in the request path. This architectural oversight creates a critical gap in multi-tenant security boundaries where isolation between different logical partitions of the broker is compromised.
The operational impact of this vulnerability allows any user with management privileges to perform unauthorized information disclosure regarding quorum queues located in virtual hosts they do not have permission to access. By targeting the /api/queues/quorum/:vhost/:queue/status endpoint, an attacker can extract sensitive Raft consensus state data including leader election status, cluster member lists, current term identifiers, and commit indices for queues residing in inaccessible vhosts. This exposure reveals cross-tenant queue names which may contain business logic or operational metadata, effectively breaking the isolation model that RabbitMQ is designed to enforce. Furthermore, access to cluster topology details such as node membership and Raft state provides attackers with valuable intelligence about the internal structure of the messaging infrastructure, facilitating further reconnaissance and potential targeted attacks against specific nodes or services within the cluster.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing proper authorization checks for resources based on user roles and resource ownership. It also maps to MITRE ATT&CK technique T1087.003 Account Discovery via Cloud or Distributed System APIs, as the attacker leverages API endpoints to enumerate accounts and queue structures across tenant boundaries. The root cause is a logic error in permission validation where role-based access control is applied too broadly without considering resource-specific constraints. This type of flaw is particularly dangerous in multi-tenant environments because it allows lateral movement within the broker's logical namespace, enabling an attacker with low-level management privileges to gather high-value intelligence about other tenants or isolated services running on the same cluster instance.
Mitigation strategies primarily involve upgrading RabbitMQ to patched versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0 where the authorization logic has been corrected to properly validate vhost-specific permissions before exposing queue status information. In environments where immediate patching is not feasible, administrators should restrict management plugin access by assigning the management tag only to trusted administrative accounts and avoiding its use for application-level service identities that require broad but non-administrative privileges. Additionally, implementing network segmentation or firewall rules to limit exposure of the HTTP API endpoints can reduce the attack surface. Regular auditing of user permissions and ensuring strict adherence to least privilege principles are essential practices to prevent similar authorization bypasses in distributed messaging systems.