# Leaked Database Connection String? Change the Password > Database URL with a password exposed on GitHub? Change the password, close public access and audit connections. Postgres, MySQL, MongoDB, Redis. Source: https://leakwatch.net/secrets/database-connection-string --- [LeakWatch](/) [Product](/product)[Live feed](/leaks)[Guides](/secrets)[Blog](/blog)[Free scan](/) 1. [Home](/) 2. [Secrets](/secrets) 3. Database Connection String Databases & keys · Secret guide # Leaked Database Connection String: what to do in the first hour Critical severityChecked liveLast verified October 2, 2026 · 5 min read 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: ```text postgres://:@/ mysql://:@/ mongodb+srv://:@/ redis://:@: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](/secrets/aws-access-key) or [Google API key](/secrets/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 1. **Change the password of that database user.** In PostgreSQL run `ALTER USER WITH PASSWORD '';`. In MySQL use `ALTER USER ''@'' IDENTIFIED BY '';`. 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). 2. **Update your applications** with the new password, and move it to a secret manager or environment variable that is not committed. 3. **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. 4. **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. 5. **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. 6. **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. 7. **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. 8. **Then clean the repository**: remove the value and rewrite history if you want to. See [I accidentally pushed an API key to GitHub](/blog/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. ## Related - [Google API Key](/secrets/google-api-key) - [Cloudinary API Secret](/secrets/cloudinary-api-secret) - [AWS access key](/secrets/aws-access-key) - [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github) - [Which vendors leak most this week](/leaks/trends) - [All secret guides](/secrets) [Get alerted next time a secret leaks — create a free account](/) LeakWatch is not affiliated with Other. ![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp) Gabriel Diyan (0xCr0c0) Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about). [GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab) LeakWatch Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about). Scan - [Product](/product) - [Live feed](/leaks) - [Trends](/leaks/trends) - [API docs](/docs) - [CI/CD](/docs?tab=ci) Read - [Blog](/blog) - [Secret guides](/secrets) - [Changelog](/changelog) - [About](/about) Verify - [Security](/security) - [Privacy](/privacy) - [Terms](/terms) - [Legal](/legal) - [Contact](/contact) - [Status](https://status.leakwatch.net) © 2026 LeakWatch [GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)