Access‑Control Flaws in RabbitMQ Could Leak OAuth Secrets and Cross‑Tenant Queue Metadata
What Happened — Researchers from Miggo disclosed two access‑control vulnerabilities in the RabbitMQ message‑broker that allow an unauthenticated attacker to (1) retrieve the broker’s OAuth client secret and (2) enumerate queue metadata across tenant boundaries. Successful exploitation could enable message‑injection attacks or full takeover of an organization’s messaging fabric.
Why It Matters for Compliance & Audit Readiness
- The flaws illustrate a classic control‑mapping gap: a “least‑privilege” policy for service‑to‑service credentials is not enforced, violating SOC 2 CC6.2 (Logical Access Controls).
- Continuous evidence of proper OAuth secret management and tenant isolation is required to demonstrate compliance; these bugs show why automated control‑monitoring is essential.
- Mapping the affected controls to your SOC 2 audit program and collecting real‑time proof of remediation (e.g., secret‑rotation logs) provides defensible audit evidence.
Who Is Affected – Cloud‑native SaaS providers, fintech platforms, and any organization that runs RabbitMQ (on‑prem or managed) for inter‑service messaging.
Recommended Actions
- Review RabbitMQ version and apply the vendor‑released patches (or upgrade to the latest stable release).
- Harden OAuth client secret handling: rotate secrets, store them in a dedicated secrets manager, and enforce scoped scopes per tenant.
- Update your SOC 2 access‑control inventory to include RabbitMQ as a critical component; map the vulnerability to CC6.2 and begin continuous evidence collection (configuration drift checks, secret‑rotation logs).
Source: The Hacker News
Technical Notes
- Attack vector: Exploitation of insufficient access‑control checks in the RabbitMQ management API.
- Data at risk: OAuth client secrets, tenant‑specific queue names, and potentially message payload metadata.
- Remediation: Vendor patches address the validation logic; no public CVE ID assigned yet.