WordPress backup and config files attackers check first

Bots scan for wp-config.php.bak within minutes of a site going live.

WordPress runs a huge share of the web, which means the bots have had years to learn exactly where the soft spots are. They don't poke around. They request a short list of known filenames straight away, and two of them leak more than almost anything else on the site: a backup copy of wp-config.php and the debug log.

Why a backup of wp-config is the jackpot

wp-config.php holds the database name, host, username, and password, plus the secret auth keys and salts WordPress uses to sign session cookies. Normally it's safe, because PHP executes it rather than serving its contents. Request wp-config.php and you get a blank response, because the server runs the code and there's no output.

The backup copy is where that protection falls apart. Edit the file with a careless editor and it leaves behind wp-config.php~ or wp-config.php.swp. Make a manual copy before changing something and you get wp-config.php.bak or wp-config.php.old. A plugin or a migration leaves wp-config.php.save. None of those end in .php, so the server doesn't execute them. It serves them as plain text. The database password that PHP was hiding is now the literal body of an HTTP response.

What the debug log gives away

The other file bots check is /wp-content/debug.log. It appears when someone enables WP_DEBUG_LOG to chase a bug and forgets to turn it off. WordPress then writes errors, warnings, and stack traces to that file continuously, and the file sits in a directory that's served to the web.

A debug log is a slow leak rather than a single jackpot, but it's a rich one. Stack traces reveal your absolute server paths, your plugin and theme names with versions, and the exact lines where things break. That's a map an attacker uses to pick known vulnerabilities for the exact plugin versions you're running. Sometimes a poorly written plugin logs query strings or tokens straight into it. Either way it's reconnaissance handed over for free, the WordPress cousin of a verbose stack trace leaking your stack through any open directory.

What a stranger does next

With the database credentials from a wp-config backup, the path depends on your host. If your MySQL accepts external connections, they connect and read or modify every table directly, including creating themselves an admin user. If it doesn't, the auth keys and salts are still a serious problem, because knowing them helps forge valid authentication cookies. Either route ends with someone holding admin on your site, and an admin in WordPress can edit theme files, which means they can run PHP, which means they own the server.

This is all automated. The same bots that try wp-config.php.bak try /wp-content/uploads/ for directory listings and /backup.sql for a stray database dump in the same pass. They aren't targeting you. They're targeting every WordPress install at once, and yours is on the list the moment it resolves.

Checking and closing it

Test the obvious names against your domain by hand. Try /wp-config.php.bak, /wp-config.php.old, /wp-config.php.save, /wp-config.php~, and /wp-config.txt. Then load /wp-content/debug.log. A 404 on each is what you want. A 200 on the config backup means rotate that database password and the WordPress salts immediately, because the file has been readable for as long as it's existed.

Then stop the files being served. Block backup extensions and the debug log at the web server, and set WP_DEBUG_LOG to a path outside the web root if you need logging at all.

# Apache: backup of wp-config served as plain text,
# debug.log readable in wp-content
# (no rules; defaults serve both)

Deleting the one file you found is not enough on its own, because the next careless editor save recreates it. The server rule is what makes the leak impossible to repeat.

The single most useful thing you can know about a fresh WordPress install is whether those backup names and /wp-content/debug.log are answering with content, because that's the first thing the bots find out too. SurfaceCheckr requests them the way any stranger would, from outside, and tells you which ones came back with a body instead of a 404. No login, no database connection, nothing your server doesn't already hand to the public.