My MySQL database got exposed without authentication. What should I do?

01Understand what’s at risk

A MySQL instance listening on 0.0.0.0:3306 with weak or missing auth gives an attacker the same power your application has — and often more:

• Full read access — every row in every table: customer records, password hashes, tokens, business data.
• Write & delete — they can modify or drop tables, plant backdoors, or hold your data to ransom.
• Lateral movement — credentials and connection strings inside your data can open other systems.
• FILE privileges — a powerful account may read server files or write web shells via INTO OUTFILE.

02Stop the bleeding — take it off the internet

The fix that matters most is making the port unreachable. Firewall it, then bind MySQL to localhost (or a private interface) so it can’t be served publicly at all.

# deny external access to MySQL
ufw deny 3306

[mysqld]
bind-address = 127.0.0.1   # localhost only

Restart MySQL after editing (systemctl restart mysql). If your app connects from another host, allow only that host’s IP — never the whole internet — and prefer a private network or SSH tunnel.

03Fix authentication and rotate credentials

An exposed server almost always means weak or missing auth. Lock it down:

1. Remove anonymous and passwordless accounts — run mysql_secure_installation and drop any user with an empty password or a % host you don’t need.
2. Set strong passwords for root and every application user, scoped to the host each connects from.
3. Rotate app credentials everywhere they’re configured (your .env / secrets) — they may have been read.
4. Rotate secrets stored in the data — API keys, tokens or hashes in the tables should be considered leaked.

-- scope the app user to one host + strong password
ALTER USER 'app'@'10.0.0.5' IDENTIFIED BY '<strong-new-secret>';
REVOKE ALL ON *.* FROM 'app'@'%';
FLUSH PRIVILEGES;

04Read the logs — who connected?

Find out whether anyone reached in. Check the general/error logs for connections from unfamiliar IPs, and your firewall logs for the exposure window.

# connections (if the general log was enabled)
grep -i "Connect" /var/log/mysql/*.log

# who is connected right now
mysql -e "SHOW PROCESSLIST;"

• Connections from unknown IPs, especially around the time tables changed, mean access — treat all data as copied.
• Unexpected users or grants (SELECT user,host FROM mysql.user) can be a planted backdoor.
• Check the binary logs for DROP/DELETE/UPDATE you didn’t run, to scope tampering.

05Recover safely from backups

If data was altered or a ransom note appeared, do not negotiate. Restore from a known-good backup taken before the exposure window.

• Restore to a freshly secured instance — never back onto a box you can’t trust.
• Keep a copy of the tampered state for evidence/analysis before overwriting.
• No backup? Capture the current state and get incident-response help; paying rarely recovers anything.

06Make sure it can’t happen again

• Never expose a database to the internet. Bind to localhost/private networks; reach it via VPN or SSH tunnel.
• Require strong auth and least-privilege accounts scoped to specific hosts.
• Back up regularly and test restores — tested backups are your ransomware insurance.
• Monitor for connections from new IPs and alert on schema changes.
• Patch MySQL and keep default/sample accounts removed.