My SQL database dump got exposed. What should I do?

01Understand what the dump contains

A SQL dump (typically produced by mysqldump, pg_dump, or a phpMyAdmin export) is a complete, human-readable snapshot of your database. It includes:

• Schema definitions — table names, column names, and indexes. This gives an attacker a complete map of your data model.
• All user records — email addresses, usernames, names, addresses, phone numbers, and any other PII stored in the users table.
• Password hashes — even hashed passwords are dangerous. MD5 and SHA-1 hashes are crackable in bulk using rainbow tables or GPU cracking rigs. bcrypt and Argon2 are stronger but not uncrackable with sufficient time.
• Configuration data — many applications store settings and credentials in database tables (WordPress wp_options, for example). These may include API keys in plaintext.
• Session tokens, payment data, or medical records — depending on your application.

02Remove the dump file and block backup extensions

First, take the file offline. Then configure your web server to refuse to serve any file with a backup or dump extension:

# move to a secure location, don't just delete (you'll need it for investigation)
mv /var/www/html/backup.sql /root/incident-backup.sql

# or if you must delete it
shred -u /var/www/html/backup.sql

location ~* \.(sql|sql\.gz|bak|backup|dump|db)$ {
    deny all;
    return 404;
}

After making the change, verify from an external network that the file returns a 404 and that no other .sql or .bak files are accessible.

03Rotate the database password

The dump itself may include the database connection credentials if they were stored in a configuration table, or the dump may have been created by a user whose password you now need to rotate. Change the database user's password immediately:

-- connect as root
ALTER USER 'appuser'@'localhost' IDENTIFIED BY 'new-strong-password-here';
FLUSH PRIVILEGES;

-- if the DB is network-accessible, also restrict the host
-- to only allow connections from the app server IP
UPDATE mysql.user SET Host='10.0.1.5'
  WHERE User='appuser';
FLUSH PRIVILEGES;

Update your application's configuration with the new password, then restart the application to confirm it connects successfully before moving on.

04Force password resets for all affected users

Password hashes are not plaintext passwords, but they are crackable — especially if they were hashed with MD5, SHA-1, or unsalted SHA-256. You must assume that an attacker with the dump will run cracking tools against the hashes and recover a significant portion of them.

The responsible action is to force a password reset for all users whose hashes are in the dump:

• Invalidate all current sessions — clear session tokens or rotate the session signing secret to force re-login.
• Set a "must reset password" flag on all user accounts or expire all password hashes so the next login requires a new password.
• Email users — inform them that you've identified a security issue and require them to set a new password. Be honest without being alarmist. Check your legal obligations on breach notification language.
• Warn about password reuse — if your users' passwords are cracked, attackers will try them on Gmail, banking apps, and other services. Prompt users to change passwords elsewhere too.

05Move backups outside the web root permanently

The root cause here is storing database backups in a web-accessible location. Fix this at the infrastructure level:

• Write backups to a dedicated backup directory outside the document root — e.g., /var/backups/db/ rather than /var/www/html/. The web server process should have no read access to this path.
• Use a dedicated backup storage service — S3, GCS, or Azure Blob Storage with a private bucket, access logging, and server-side encryption enabled.
• Encrypt dumps before storing them — pipe through gpg or use your cloud provider's encryption at rest.
• Rotate and delete old backups — set a retention policy so stale dumps aren't accumulating in perpetuity.
• Audit what your automated backup scripts produce and where they write — cron jobs creating dumps in the web root are a common cause of this issue.