MySQL exposed to the internet

MySQL on a public IP is a brute-force target with no rate limiting and no account lockout. It will answer authentication attempts as fast as they arrive, indefinitely, and internet-wide scanning finds port 3306 within minutes of it becoming routable.

That much is expected. What makes it worse than it sounds is what a successful login reaches.

A login is not confined to the database

Three escalation paths, in the order attackers try them:

FILE privilege → read and write files. An account with FILE can read any file the mysql OS user can read, and write files anywhere it can write:

SELECT LOAD_FILE('/etc/passwd');
SELECT '<?php system($_GET[0]); ?>' INTO OUTFILE '/var/www/html/x.php';

That’s a web shell, from a database login. secure_file_priv is what stops it.

UDF → arbitrary code. With FILE and INSERT on mysql, an attacker writes a shared object into the plugin directory and registers it as a user-defined function. The function then executes native code inside the mysqld process, as the mysql user. This is the classic MySQL RCE and it needs no vulnerability — only privileges.

Credentials for everything else. The mysql.user table holds password hashes. On mysql_native_password those are unsalted SHA-1 — cheap to crack offline, and people reuse database passwords.

So “there’s nothing sensitive in that database” is the wrong question, the same way it is for Redis and Postgres. The data is not the prize. The host is.

What actually gets servers compromised

Roughly in order:

1. A weak password on an account with '%' as its host — reachable from anywhere, and guessable.
2. GRANT ALL ON *.*, so the account that fell has FILE and the UDF path is open.
3. An anonymous account left over from a legacy install — no password required at all.
4. An EOL server. MySQL 8.0 reached end of life in April 2026 and gets no further security fixes.

Notice that none of these are exotic. They’re the defaults of a setup that was made to work quickly.

The shortest path from exposed to closed

1. Bind to a private interface, or skip-networking if nothing connects over TCP. This alone closes it.
2. Firewall 3306 — and 33060 if MySQL’s X Protocol is running.
3. Remove '%' hosts and FILE/SUPER from applications — bounds what a fallen credential reaches.
4. Set secure_file_priv = NULL — closes both the web-shell and UDF paths even if a grant is wrong.

Steps 1 and 2 take two minutes.

Verify it worked

Is it reachable? From another host — not the server:

mysql -h your.db -u root -p --connect-timeout=5

A timeout is the goal. An authentication prompt means the port is open to that network.

Were you hit? Look for the escalation artefacts first — these are cheap and decisive:

-- Accounts you did not create, especially wide ones
SELECT user, host, plugin FROM mysql.user
WHERE host = '%' OR Super_priv = 'Y' OR File_priv = 'Y'
ORDER BY user;

-- User-defined functions: this table is normally EMPTY
SELECT * FROM mysql.func;

Any row in mysql.func on a server you didn’t deliberately extend is a finding. That is the UDF path, and it means code execution, not a data leak.

Check for files written where they shouldn’t be:

SELECT @@secure_file_priv, @@plugin_dir;

sudo ls -lat /var/lib/mysql-files/ 2>/dev/null
sudo find /usr/lib/mysql/plugin -newer /etc/mysql/my.cnf -type f 2>/dev/null
sudo ls -lat /var/www/html | head

Failed logins are only visible if you log them:

sudo grep -ci 'Access denied for user' /var/log/mysql/error.log

A high count is expected on an exposed server and is not itself a compromise. An Access denied count that suddenly stops is more interesting than one that keeps climbing — it can mean the guessing succeeded.

Before you apply this

If it was internet-reachable with a guessable password, assume compromise rather than misconfiguration. Closing the port does not remove anyone already in.

Minimum response:

1. Firewall the port first. Do not restart mysqld — a restart clears information_schema.processlist and unloads UDFs, destroying the evidence that would tell you what happened.
2. Check mysql.func, mysql.user, the plugin directory, and the web root for anything written recently.
3. Rotate every credential: database accounts, and anything the data held — application user password hashes, API keys, tokens, session secrets.
4. If mysql.func had entries, or files appeared in the plugin directory or web root, rebuild the host. Code ran as the mysql user; you will not establish by inspection that you found all of it.

Treat the data as disclosed regardless. And rotate application-user password hashes specifically — if your users’ hashes were in that database, your users are affected even though nothing of yours was “sensitive”.

Related

• Hardening MySQL and MariaDB — the full checklist.
• Restrict file privileges — the control that closes the escalation.