My RabbitMQ broker is accessible with default credentials. What should I do?
RabbitMQ ships with a well-known default login — guest / guest — and if your broker is reachable from the internet with that account active, anyone can read your message queues, inject messages, and snoop through the management UI. Here’s how to lock it down and rotate.
First: don’t panic — disable the default user and firewall the ports.
guest/guest is the first thing every scanner tries. Close the AMQP and management ports and kill the default account now, then rotate and review what flowed through the queues.
// the 60-second version
- Firewall ports 5672 and 15672 (AMQP + management UI) now.
- Delete or lock the default
guestuser; create real accounts. - Rotate credentials for every app that connects, and any secrets seen in messages.
- Review the management UI / logs for unfamiliar connections.
01Understand what’s at risk
A message broker sits in the middle of your system, so access to it is access to your data in motion:
- Read your queues — messages often carry PII, tokens, internal events and business data.
- Inject or replay messages — trigger application actions, poison workflows, or cause downstream damage.
- Management UI (port 15672) — with
guest/guestit exposes users, vhosts, queues and config in a friendly web interface. - Denial of service — purge queues or overwhelm consumers.
By default guest is restricted to localhost — but a surprising number of deployments loosen that (loopback_users = none) or proxy the UI, re-enabling guest from anywhere. If yours did, assume it was found.
02Stop the bleeding — firewall and disable guest
ufw deny 5672 ufw deny 15672
Then remove or lock the default user:
rabbitmqctl delete_user guest
# at minimum, restrict guest back to loopback in the config
Keep AMQP and the management UI on a private network; front the UI with a VPN or authenticating proxy.
03Create real accounts & rotate
- Create per-application users with strong passwords and minimal permissions, scoped to the vhosts they need.
- Update every service’s connection string with the new credentials and remove guest from all of them.
- Rotate any secrets that may have travelled through messages and been read.
rabbitmqctl add_user app '<strong-secret>' rabbitmqctl set_permissions -p / app "^app-.*" "^app-.*" "^app-.*"
04Read the logs / UI — who connected?
Check the RabbitMQ logs and the management UI’s connections view for clients you don’t recognise:
grep -iE "connection|accepting|authenticated" /var/log/rabbitmq/*.log
- Connections from unknown IPs, or guest logins from non-loopback, indicate access.
- Review queues for messages you didn’t publish (injection) and unexpected consumers.
05Enable TLS & harden
- Turn on TLS for AMQP and the management UI so credentials and messages aren’t sent in clear.
- Disable the guest account permanently; never re-enable the loopback bypass on an exposed host.
- Set per-vhost, least-privilege permissions for every user.
06Make sure it can’t happen again
- Never expose broker ports publicly — private network or VPN only.
- Change or disable all default credentials on every service.
- TLS everywhere; least-privilege users per app.
- Monitor connections and alert on new client IPs; keep RabbitMQ patched.
Was this guide useful?
These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.