RabbitMQ management API allows cross-vhost queue enumeration

A missing-authorization flaw in the RabbitMQ management API. NVD scores CVSS 3.1 = 5.0 (medium) — network-reachable, low-privileged authentication required, no user interaction, low confidentiality impact only.

What the flaw is (per NVD): the management API omits an authorization check on certain listing endpoints, so an authenticated user with any credentials inside a virtual host can enumerate all queue and exchange names in that vhost and read queue message counts and consumer counts, regardless of the permissions actually granted to that user on those queues.

The impact depends on how the deployment is using vhosts. On a single-tenant deployment the exposure is limited to metadata a legitimate operator would already see. Where RabbitMQ vhosts are the isolation layer between multiple SaaS tenants — which the pattern discourages but the industry uses anyway — a low-privileged user can enumerate the queue topology of tenants adjacent to their own within the same vhost boundary.

Status: Fixed in 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15 per the RabbitMQ security advisory GHSA-9q2j-2hq8-22r2. Discovered and reported by Miggo’s security team. No known exploitation in the wild ahead of disclosure.

What to do: Upgrade to one of the fixed lines above. Multi-tenant deployments that were relying on vhosts for tenant isolation should also revisit that assumption on the architecture level — the patch closes this particular enumeration path, not the broader question of whether a shared broker with vhost-scoped authorization is the right primitive for tenant separation.