Leaked Database Connection String? Change the Password

A database connection string with the password inside is a username and password for your data, plus the address to use them at. Unlike an API key it has no provider console where you click “revoke”: the fix is to change the password of that database user, and to make sure the database should not be reachable from the whole internet in the first place. Do both, then look at what was read.

Check your GitHub account for leaked secrets — free

Provider: Other
Severity: Critical
Impact: Payments and customer data
Checked live by LeakWatch: Yes

What a database connection string looks like

LeakWatch recognizes URLs for PostgreSQL, MySQL, MongoDB and Redis that include both a user and a password:

postgres://<user>:<password>@<host>/<database>
mysql://<user>:<password>@<host>/<database>
mongodb+srv://<user>:<password>@<cluster-host>/<database>
redis://<user>:<password>@<host>:6379

The password is the secret; the host and database name are information that tells an attacker where to go. A URL without credentials (redis://localhost:6379) is configuration, not a leak, and a URL with a user but no password is not reported either.

What this is not: an ORM or framework config that keeps the password in a separate variable (check that variable instead), or a cloud provider key. If the same file also holds an AWS or Google key, use the AWS access key or Google API key guide as well.

How database connection strings get leaked

DATABASE_URL in a committed .env. The standard single-variable convention used by Heroku-style platforms, Rails, Django and most Node setups.
Framework config files. settings.py, config/database.yml, application.properties or knexfile.js with the URL inline.
Docker and orchestration files. docker-compose.yml, Kubernetes manifests or Helm values with the URL as a plain environment variable instead of a secret.
Dumps, seed scripts and migrations run against a real database, with the URL in a comment or a shell command.
Hosting dashboards. A URL copied from a managed database page (the “connection string” button) and pasted into an issue, a chat or a README.

What to do in the first hour

Change the password of that database user. In PostgreSQL run ALTER USER <name> WITH PASSWORD '<new>';. In MySQL use ALTER USER '<name>'@'<host>' IDENTIFIED BY '<new>';. In MongoDB Atlas, open Database Access, edit the user and set a new password. For Redis, change the requirepass setting or the ACL user’s password. On managed databases (RDS, Supabase, Neon, Render and others) use the reset-password option in the provider’s dashboard. New connections with the old password fail immediately; existing connections may stay open, so also terminate them (pg_terminate_backend in PostgreSQL, KILL in MySQL).
Update your applications with the new password, and move it to a secret manager or environment variable that is not committed.
Close the door. Check whether the database accepts connections from anywhere. Restrict it with the provider’s network allowlist (for instance Atlas Network Access or a cloud security group), use private networking where possible, and require TLS.
Find out whether someone connected. Check the connection logs of the database or provider for addresses you do not recognize, and the list of current sessions (pg_stat_activity in PostgreSQL, SHOW PROCESSLIST in MySQL). Look at the period since the exposure.
Check what they could have changed. List the users and roles (\du in PostgreSQL) and look for ones you did not create, new tables, changed permissions, and, for MongoDB and Redis, unexpected ransom-note collections or keys. Compare against a recent backup.
Reduce what a single user can do. Give each application its own database user with only the permissions it needs, not the owner or superuser account.
Assess personal data. If the database holds personal data, find out whether it was accessed. In the EU, a personal-data breach may have to be reported to the supervisory authority within 72 hours of becoming aware of it. Talk to a qualified adviser rather than deciding alone.
Then clean the repository: remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub.

Not sure what else leaked from the same repository? Run a free scan.

Not sure what else leaked? Run a free scan.

Revoke it at your database provider

There is no single revocation page: the credential is a database user, so “revoking” means changing or deleting that user’s password in the database itself or in your provider’s console (RDS, Atlas, Supabase, Neon, Render, DigitalOcean and the like all have a reset-password option). If you run the database yourself, use the SQL command for your engine from step 1. If the connection string belongs to a shared admin user, create a new user for each application and delete the old one, rather than changing the password and redistributing it.

How LeakWatch detects it

LeakWatch matches a PostgreSQL, MySQL, MongoDB or Redis URL that contains both a user and a password. This type is checked live: LeakWatch tries a read-only connection to see whether the credentials still work, and if they do it reads only structural metadata (database, table and collection names), never row data. It skips localhost and private network addresses, since the goal is to flag credentials reachable from the public internet.

LeakWatch can check whether a detected key is still active with a read-only request to Other. It never reads your data or spends your credits.

FAQ

My database is not reachable from the internet. Do I still need to act?

If it is only on a private network, a leaked password is less urgent, but not harmless: anyone who gets onto that network, including through a different leaked credential, can use it. Change the password anyway, and keep the network restrictions.

Do I need to rotate the password if the leaked URL was for a local or staging database?

Rotate it if the staging database holds real data or shares a password with production. If it is a throwaway local database with no real data, deleting the commit is reasonable, but rotating is a minute of work and removes the doubt.

Which part of the URL is the secret?

The password. The host, port and database name are not secrets, but they tell an attacker where to connect, which is why closing network access matters as much as changing the password.