RabbitMQ OAuth Failures: Leaking Secrets and Bypassing Tenants
Has anyone else dug into the RabbitMQ disclosure from Miggo today? It’s a textbook example of why least privilege access control in message brokers is so critical. We're looking at two separate issues that fundamentally break trust in the broker's identity layer.
The flaws impact the access control mechanisms, specifically:
- OAuth Client Secret Leakage: The vulnerability leaks the broker's confidential OAuth client secret.
- Cross-Tenant Metadata Exposure: A bypass allowing attackers to peek into queue metadata across different tenants.
If you're running RabbitMQ in a multi-tenant environment (common in enterprise SaaS), the metadata exposure is particularly nasty. It essentially removes the isolation guarantees you thought you had, allowing attackers to map out infrastructure and queue names they shouldn't see.
For those scanning your environments, check your RabbitMQ management interface logs for unusual pattern matching or unauthorized API usage. Here’s a basic KQL query to spot potential metadata enumeration attempts if you're shipping logs to Sentinel:
RabbitMQManagementAudit
| where RequestMethod == "GET" and Url contains "api/queues"
| where HttpResponseCode == 200
| project Timestamp, UserIP, UserName, Url
| order by Timestamp desc
Additionally, verify your rabbitmq_auth_backend_oauth2 configuration isn't inadvertently exposing sensitive details in debug logs or error responses.
How is everyone handling the upgrade path? Are you segregating management API access at the network level as a stopgap while patching, or is a full rollback of the OAuth integration the only safe play right now?
We're restricting management API access via IP whitelisting immediately as a temporary fix. We don't expose the UI publicly, but the internal risk is still real given the OAuth secret leak. Upgrading is going to be a headache due to the Erlang version dependencies on our legacy nodes, so we're likely blocking the specific endpoint paths on the internal load balancer until we can schedule maintenance.
Great catch on the KQL. I'd also recommend setting up correlation rules to look for spikes in 401 or 403 responses on the management port, which might indicate attackers actively probing for the tenant bypass.
cat /var/log/rabbitmq/rabbit@hostname.log | grep -E 'HTTP access denied' | awk '{print $1, $2}' | sort | uniq -c
If you see a single IP racking up denied requests, you might already be getting scanned.
This is a nightmare for anyone using RabbitMQ as a central event bus for microservices. If the OAuth secret leaks, an attacker could theoretically issue their own tokens and authenticate as the broker itself. I'm advising my clients to rotate their Client Secrets at the Identity Provider (IdP) immediately, regardless of whether they see signs of exploitation.
Solid points from everyone. Beyond the immediate lockdown, you should audit your configuration files for any hardcoded credentials. If the secret is exposed, you must rotate it immediately at the provider and update the broker. You can scan your configs for potential hardcoding issues with:
grep -iR 'oauth\.clients' /etc/rabbitmq/
Also, ensure you strictly define the auth_oauth2 scopes to minimize the blast radius if an attacker attempts to reuse a compromised token before rotation completes.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access