The admin panel you left unlocked

Is your phpMyAdmin sitting on the open internet?

Open a new tab and type your domain followed by /phpmyadmin. If a login form loads, so it does for everyone else on the internet. You installed that panel once because editing the database by hand over SSH got old, it worked, and you never thought about it again. That was probably a year ago.

The password feels like protection, and against a casual visitor it is. Against the people who actually go looking it does almost nothing, because the form renders before the password matters at all. The page itself announces that you're there and tells them exactly what you're running.

How a stranger finds it before you remember it exists

Nobody guesses your domain and types /phpmyadmin on a hunch. They don't have to.

Mass scanners sweep the entire IPv4 space for common paths every single day. /phpmyadmin, /adminer.php, /pma, /dbadmin, /mysql. When one returns a 200 and renders a recognizable login form, your host gets logged in a database of live targets that gets traded and resold. Your robots.txt can make it worse: if it lists Disallow: /phpmyadmin, you've helpfully published the exact path you were trying to hide. Shodan and similar services index these panels continuously, so an attacker can search for "every phpMyAdmin reachable in your country" and get a list. You're on it or you're not. You don't get a say.

The login page also leaks its own version. phpMyAdmin prints its release in the footer and in static asset paths. That version maps directly to a list of known CVEs. So before anyone types a single character into the password box, they know the software, the version, and whether there's a public exploit that skips the password entirely.

yoursite.com/phpmyadmin
phpMyAdminv5.1.1
Username
Password
phpMyAdmin 5.1.1·2 known CVEs for this build
Reachable from any IP on earth
The login form fingerprints itself. Product, version, and a public list of holes, before anyone types a password.

What happens after the form loads

Once a panel is confirmed reachable, the password is just one of several ways in, and often the weakest part of the chain.

The most common attack is the dumbest one: credential stuffing. Bots throw lists of leaked username and password pairs at the form, thousands per minute, until one works. Database panels are frequently protected by root with a password someone set during a frantic deploy and never rotated. If you ever ran MySQL with a default or empty root password and exposed phpMyAdmin, that's not a maybe, that's an open door. Beyond brute force, an outdated phpMyAdmin build can carry authentication bypass or remote-code-execution bugs that don't need a valid password at all. The version banner told them which one to try.

When they get in, they have your database. All of it.

  • Read every table: users, password hashes, emails, payment references, private messages.
  • Dump the whole schema with one click and walk away with a complete copy.
  • Run DROP or UPDATE against anything, including wiping you and leaving a ransom note in a new table.
  • On many setups, write a file to the web root through SQL and turn database access into a shell on the server.
day 0Scanner logs your /phpmyadmin
+1hVersion mapped to known CVE
+3hCredential stuffing starts
+1dFull database dumped
None of this involves a person watching your site. It's automated from discovery to dump.

You will not get an email about this. A successful login looks exactly like you logging in. The first sign is usually a customer asking why their data is for sale, or your tables simply gone.

You can check this from outside in seconds

This is the good news, and it's why the fix is so cheap relative to the risk. The exposure is visible from the outside, so you can confirm it the same way an attacker would, without touching your server.

  1. Open your site's domain in a browser.
  2. Add /phpmyadmin to the URL. Then try /adminer.php, /pma, and /dbadmin.
  3. If any of them returns a login form instead of a 404 or a connection refused, that panel is public.

Doing that by hand covers four or five paths. A real scan checks dozens of them plus the version fingerprint and the robots.txt giveaway, which is the kind of sweep an external scanner runs in minutes. SurfaceCheckr runs that pass and tells you which database panels answer, and it reads them exactly the way a stranger's scanner does, from the outside. It never logs in or tries your credentials, so it can't tell you whether your authenticated routes are sound the way a pentest would. What it tells you is whether the login form is reachable at all, which is the one fact that decides whether everything above is your problem.

How to take it off the internet

A better password won't save you here. The fix is making the panel unreachable from the public internet in the first place.

The cleanest answer: don't expose phpMyAdmin at all. Reach your database admin tooling over an SSH tunnel or a VPN, so the panel only ever listens on localhost and your laptop forwards to it. No public route, nothing to scan, nothing to brute force. If you genuinely need it web-accessible, put it behind an IP allowlist or an authenticating reverse proxy, so the form never renders for an address you don't recognize.

# nginx: phpMyAdmin served to the world
server {
listen 443 ssl;
server_name yoursite.com;
location /phpmyadmin/ {
  alias /usr/share/phpmyadmin/;
}
}
The panel that only listens on localhost can't be scanned, fingerprinted, or brute forced.

If you can't tunnel today, the stopgap is an IP allowlist on that location block and an immediate rotation of the database password. But the real fix is simple: a database admin panel has no business being something a stranger can load.

Find it before someone else does.

Paste your domain. The grade and issue count are free, and you'll see in a couple of minutes exactly what's reachable from outside.