Leaked RabbitMQ/AMQP Connection String: what to do in the first hour

• Application configuration. A CELERY_BROKER_URL, AMQP_URL or RABBITMQ_URL setting in a settings file or a Docker Compose file, committed with the code.
• Environment files. A .env file that lists the broker URL next to the database and API credentials.
• Infrastructure code. A Helm chart, a Kubernetes manifest or a Terraform file with the broker password written in plain text instead of a secret reference.
• Local tutorials. A broker started with a default user for a demo, then its URL copied into a repository.
• Logs and crash reports. A framework that prints its broker settings on startup, or an exception that includes the connection URL.

1. Identify the user and the broker. Read the user name and the host from the string. Find the broker in your own infrastructure, or in the console of the hosted service that runs it, and confirm that the user is the one in the leaked string.
2. Create or pick a replacement credential. Prefer a new user for the service, with only the permissions it needs on the virtual host it uses. Store its password in your secret manager.
3. Deploy the new connection string to every service that uses the broker, then confirm that each one still publishes and consumes.
4. Change the exposed password. Use the steps in the RabbitMQ revoke section below. Once the old password is gone, any client still using it cannot reconnect.
5. Close the open connections that used the old credential, so that a session already logged in does not keep running.
6. Review the queues and the logs. Check the broker’s management views for the period since the exposure. Look for new users, changed permissions, unexpected connections from unknown addresses, and messages published to queues you did not expect.
7. Check what the messages carried. If the queues hold personal data, orders or tokens, decide whether any of it was read, and follow your incident process if it was.
8. Clean the repository. Remove the string from the working tree and rewrite history if the repository is public. See I accidentally pushed an API key to GitHub.

Not sure what else leaked? Run a free scan.

RabbitMQ does not issue separate tokens for AMQP. The user name and password are the credential, so revocation means changing the password or removing the user. In the management interface, open the admin area, choose the user from the list, and set a new password or delete the user and create a replacement. From a shell on the broker host, rabbitmqctl change_password does the same job for the named user. Then close the open connections for that user from the connections page or with the matching rabbitmqctl command. Hosted services have their own consoles for users and connections, and the steps there replace these. If your setup differs from this description, follow the current RabbitMQ documentation on users and authentication.

The rule is called “RabbitMQ/AMQP Connection String”. It matches a URL that starts with amqp:// or amqps://, then a user name of 3 to 50 characters that is not whitespace, a colon, @ or a slash, then a password of 3 to 50 characters with the same restriction, then an @ sign and a host made of letters, digits, dots, hyphens, percent signs, slashes and colons. The match needs the whole user-and-password section to be present, so a bare scheme or a string without credentials is not reported. The severity is critical, because the credential can reach every queue the user can open. This type is not checked live: LeakWatch does not connect to the broker with the value it found, so a hit tells you the string has the right form, not that it still works.