RabbitMQ OAuth Failures: Leaking Secrets and Bypassing Tenants

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.

Don't forget to check your offline backups. If the metadata exposure was active before patching, historical definitions exports might contain evidence of cross-tenant access. It's worth auditing your export files to ensure no rogue permissions were persisted to disk. You can quickly scan for bindings that grant access to specific vhosts using:

jq -r '.bindings[] | select(.destination_type=="queue") | .vhost' definitions. | sort | uniq -c

To ensure the leaked secret wasn't weaponized before rotation, verify your OAuth provider's logs for access token requests originating from unauthorized IPs. If you can't access IdP logs easily, scrub the local RabbitMQ logs for successful API calls from the broker's client ID that didn't originate from known internal nodes. A quick Bash one-liner helps isolate these:

zcat /var/log/rabbitmq/rabbit@$(hostname).log.* | grep "accepted" | awk '{print $1, $2, $7}'

This helps confirm if the exposure led to active lateral movement.

Beyond rotation, don't forget that RabbitMQ caches permissions. You'll likely need to trigger a permission cache refresh or restart nodes to invalidate any tokens issued via the leaked secret. I'd also run an immediate audit on active connections to spot lingering sessions from the exposure window.

rabbitmqctl list_connections client_properties peer_host auth_mechanism

This helps identify if any users connected with unexpected mechanisms or IPs before you locked it down.

Building on Nate's detection logic, focus specifically on successful 200 OK responses for metadata exports. If the secret was leaked, attackers might authenticate successfully rather than fail. You'll want to audit for bulk data dumps.

RabbitMQLogs
| where HttpCode == 200
| where Url endswith "/api/definitions"
| summarize Count=count() by SourceIP, AuthUser

This helps confirm if credentials were used to exfiltrate configuration or queue definitions.