Replace the RabbitMQ guest user

The fix

# Create a real admin, then delete guest
rabbitmqctl add_user app_admin "$(openssl rand -base64 24)"
rabbitmqctl set_user_tags app_admin administrator
rabbitmqctl set_permissions -p / app_admin '.*' '.*' '.*'

rabbitmqctl delete_user guest

Why it matters

Every RabbitMQ install ships with a user named guest, password guest, holding the administrator tag and full permissions on the default virtual host. It is the single most universally known credential in the message-broker world, and scanners try it first.

RabbitMQ’s mitigation is real but narrow: guest can only connect over loopback. The loopback_users setting lists users restricted to local connections, and guest is on it by default. So a remote AMQP client presenting guest/guest is refused — the credential works only from the broker host itself.

That’s genuinely helpful, and it’s why a default RabbitMQ isn’t immediately ownable from the internet. But it’s a thin line, and there’s a specific way people cross it.

The disaster: loopback_users = none

The moment someone needs a remote client to connect and reaches for guest, they hit the loopback restriction, and search for how to remove it. The answer they find is:

# rabbitmq.conf — DO NOT do this
loopback_users = none

That removes the loopback restriction from every user, including guest. Now guest/guest authenticates from anywhere, with administrator rights, on a broker that is very likely also exposing its ports. That is a fully open, admin-level message broker reachable from the internet — and it’s a configuration people apply deliberately, to fix a connection problem.

Never set loopback_users = none. If a remote client needs to authenticate, give it a real user. That’s the whole fix, and it’s less work than the dangerous one.

Delete guest, don’t just restrict it

Leaving guest in place — even loopback-only — means the well-known credential still works for anything with local access, which includes a compromised co-located process. Once you have a real administrator account, delete it:

rabbitmqctl delete_user guest

If you can’t delete it for some legacy reason, at minimum change its password and strip its tags and permissions so it can do nothing.

Create scoped users, not more admins

The replacement for guest is not one shared admin that every app uses. That just renames the problem. Each application gets its own user, scoped to the virtual host and permissions it needs, with no administrator tag. The admin account you create here is for administration, used rarely — the same logic as Elasticsearch’s elastic and Postgres superuser.

Verify it worked

List users and their tags:

rabbitmqctl list_users

guest appearing here is the finding — delete it. Any application user with the administrator tag is a second finding.

Confirm the loopback restriction is intact — this is the critical check:

rabbitmqctl environment | grep -A3 loopback_users
grep loopback_users /etc/rabbitmq/rabbitmq.conf

loopback_users = none, or an empty list, is an emergency if the broker is reachable remotely.

Prove guest cannot connect remotely — from another host:

curl -su guest:guest http://your.broker:15672/api/whoami -o /dev/null -w '%{http_code}\n'

Expect 401 (or a refused connection if the management port is firewalled, which is better). 200 means guest works remotely — full compromise.

Test local guest too, to confirm you actually removed it:

rabbitmqctl authenticate_user guest guest 2>&1 | tail -1

Expect an error, not success.

Before you apply this

Deleting guest breaks anything that authenticates as guest — and because guest only works locally, that means processes on the broker host: a local worker, a health check, a deploy script, or a development tool that never had its own credentials because localhost “just worked”.

Find them before you delete:

rabbitmqctl list_connections user peer_host | grep -w guest

That shows current guest connections and where from (all loopback, by definition). Anything there needs its own user first.

Migrate, don’t flip:

1. Create the real admin account and each application’s scoped user.
2. Update every client’s connection string — including local ones using guest.
3. Confirm each connects as its new user: rabbitmqctl list_connections user.
4. Then delete guest.

Do not “fix” a remote-connection problem by touching loopback_users. The whole point of this page is that the remote client needs a real credential, not a lifted restriction on a shared one. If you inherited a broker with loopback_users = none, treat it as an incident: assume guest has been usable remotely, create proper users, remove the setting, delete guest, and rotate anything that credential could have reached.

Related

• Restrict network listeners — the ports guest would connect over.
• Virtual host permissions — what the replacement users should be scoped to.
• RabbitMQ exposed to the internet — guest plus open ports.