Is port 3306 (MySQL) exposed to the internet, and is that a ransom target?

Why MySQL’s own defaults leave an opening

A fresh MySQL installation is narrower than people assume, but not as narrow as they’d like. MySQL’s own reference manual states that installation “creates only a root@localhost superuser account that has all privileges and can do anything” — there’s no sprawl of default accounts to clean up, just the one. The catch is what happens to that single account: the manual is explicit that “if the root account has an empty password, your MySQL installation is unprotected: anyone can connect to the MySQL server as root without a password and be granted all privileges.” Whether that password gets set automatically depends entirely on how MySQL was installed — some installers generate and display a random password during setup, others leave the step to the administrator, which means the same software can land in a secured or an unprotected state purely based on which install path was used, with no error or warning to flag the difference.

A documented pattern of abuse, not a hypothetical one

This gap has already been exploited at scale, and the timeline is well documented. In February 2017, after a wave of ransom attacks had already hit tens of thousands of exposed MongoDB servers, BleepingComputer reported that the same pattern moved to MySQL: attackers “attempted to brute-force their way into MySQL root accounts,” and once in, deleted the database’s contents and replaced them with a table demanding 0.2 Bitcoin, directing victims to “contact this email with your IP or database name to recover your database.” The campaign ran for roughly 30 hours and, per the researchers who tracked it, traced back to a single source IP — a reminder that this kind of attack doesn’t require a sophisticated operation, only an internet-reachable database with a weak or absent root password.

How to check your own exposure

AdminKit’s open ports check tests whether port 3306 on your own public IP responds from outside your network, with your consent and only against the IP making the request — confirm your current public IP first with what is my IP. A reachable port 3306 isn’t automatically a breach, but it does mean your root account’s password, or lack of one, is the only thing standing between your data and the exact scenario BleepingComputer documented.

How to fix it

• Confirm the root account has a strong, unique password — don’t assume your install method set one, since MySQL’s own documentation notes this varies by installer.
• Bind mysqld to a private or loopback address in its configuration instead of listening on every interface, so a public IP on the host doesn’t automatically make the database reachable.
• Add a firewall rule restricting port 3306 to the specific application servers that need it, rather than relying on the database’s own authentication as the only barrier.
• Remove any additional accounts with blank passwords or overly broad host wildcards, since the 2017 campaign’s entry point was exactly this kind of leftover default.
• If remote database access is genuinely needed, put it behind a VPN or an SSH tunnel rather than a direct port forward, so the authentication step isn’t the only thing standing between port 3306 and the open internet.

None of this requires giving up remote database access entirely — it requires making sure a reachable port 3306 always sits behind a real password and, ideally, a second layer of network-level restriction, rather than depending on the install step having quietly done that for you.

The same exposed-database pattern BleepingComputer documented for MySQL also applies to PostgreSQL and to Redis, where a missing password turns a reachable port into a direct line to the data behind it.

Defensive use only

Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.