Forgotten WordPress Files That Leak Your Passwords: A Cleanup Checklist

Yes, the files you forgot about can be the easiest way into your WordPress site. A leftover debug.log, a copy of wp-config.php saved as .bak, an exposed .git folder or an old staging site can give an attacker your database password and server details without any hacking skill at all. The fix is usually simple once you know where to look. Below you’ll find what these leftovers are, why they’re dangerous, and a checklist you can work through this week.

Why leftover files are such an easy target

Most people picture website attacks as someone cracking a password or exploiting a plugin bug. Many attacks are much lazier than that. Automated scanners sweep the internet looking for files that should never have been public, then collect whatever they find.

The scale is large. In 30 days of data, Wordfence recorded a little over 6.5 million attempts to find wp-config.php backup files, and the company said this shows that scanning for configuration files is widespread among malicious actors. Your site doesn’t have to be famous to get probed. If it’s online, it’s on someone’s list.

A larger example shows where this can lead. In the EMERALDWHALE operation, attackers relied only on scripts and files left exposed on web servers. They found more than 67,000 URLs with an exposed /.git/config path and stole about 15,000 cloud credentials, and the target list alone was being sold for $100. No zero-day exploit was involved, only forgotten files.

Leftover #1: The debug log

What it is

When something breaks, developers often switch on WordPress debug mode so errors are written to a log file. That’s a normal part of troubleshooting. The trouble starts when debug mode stays on after the fix.

Why it leaks

By default, WordPress saves debug.log to the publicly accessible wp-content folder, so anyone who visits the log file’s URL can read the error log, which can expose sensitive server information. WPScan notes that these logs are often left on live production websites, can contain information useful to an attacker, and usually sit at the predictable path /wp-content/debug.log. They’re so common that many of them can be found through Google using the right keywords.

Error logs can reveal file paths, plugin names and versions, database errors and sometimes fragments of user data. Each detail helps an attacker plan the next step.

How to fix it

Acunetix advises turning off debug mode on production sites right away by setting WP_DEBUG to false in wp-config.php, and removing existing debug log files or restricting access to them.

1. Open wp-config.php and confirm the line reads define( 'WP_DEBUG', false );.
2. Delete /wp-content/debug.log if it exists.
3. If you need logging on a live site, point WP_DEBUG_LOG to a file path outside your public web folder, and keep WP_DEBUG_DISPLAY set to false so errors never print on screen.
4. Visit yourdomain.com/wp-content/debug.log in a private browser window. You want a “not found” or “forbidden” response.

Leftover #2: Stray copies of wp-config.php

What it is

The wp-config.php file is the master key to your site. It holds your database credentials, secret keys, table prefix and required file paths, and an attacker who gets it has information that can lead to data theft and even a full site takeover.

Why copies are worse than the original

Normally the original file is safe to leave where it is. Files ending in .php run through the PHP interpreter, so a visitor sees a blank page, not your settings. But many web servers deliver a backup copy such as wp-config.bak exactly as written, which reveals the source code and, for a WordPress configuration file, the database credentials.

These copies get created in very ordinary ways. A common habit is to copy the file and add an extension such as .txt, .bak or .html before editing, and attackers use search queries like inurl:wp-config.php intext:DB_PASSWORD to find them. Sometimes nobody makes the copy on purpose at all: editing software can back up wp-config.php automatically without telling the developer.

How to fix it

• List every file in your site’s root folder through your host’s file manager or SFTP, including hidden files.
• Look for names like wp-config.php.bak, wp-config.old, wp-config.txt, wp-config.php~, wp-config.php.save or .swp files.
• Delete them from the server. If you need a backup, store it on your own computer or in protected storage, not in the web folder.
• If a copy was ever public, assume the credentials are compromised. Change your database password and generate new secret keys.

Leftover #3: Old backup archives and version control folders

Full-site backups saved as .zip or .sql files in the web root carry the same risk on a bigger scale: your whole database, including customer and user records, in one downloadable file. Exposed .git folders are a cousin of this problem, as the EMERALDWHALE case shows, because they can contain configuration and credentials from your development history.

• Search your public folders for .zip, .tar.gz, .sql and .bak files and move or delete them.
• Check whether yourdomain.com/.git/config loads. If it does, remove the folder from the server or block access to it right away.
• Use a backup system that stores copies off the web server entirely.

Leftover #4: The forgotten staging site

What it is

A staging site is a copy of your website used to test changes before they go live. It’s a smart practice, until the project ends and the copy is left running on a subdomain like staging.yourdomain.com or dev.yourdomain.com.

Why it leaks

Sucuri points out that a staging site can hold much of the same sensitive information as the live site, and a publicly reachable staging site can be hacked through vulnerable software, weak credentials or exposed files. Abandoned staging sites rarely get plugin updates, so they become the weakest door into a server that may also host your real site. Sucuri’s advice is plain: staging should not be open to anyone who finds its URL.

How to fix it

1. List every subdomain and subfolder copy of your site that exists, including ones a past developer set up.
2. Delete any you no longer use, along with their databases.
3. For staging sites you keep, require a password at the server level, keep them updated like your live site, and use different admin passwords.
4. Remove real customer data from staging copies where you can.

A quick self-check you can do today

• Try /wp-content/debug.log, /wp-config.php.bak and /.git/config on your domain. Every one should return “not found” or “forbidden.”
• Search Google for site:yourdomain.com and scan the results for staging copies, logs or odd file names.
• Confirm WP_DEBUG is false on your live site.
• Review your root folder for anything with .bak, .old, .txt, .zip or .sql on the end.
• Write down who has access to your hosting account, and remove anyone who no longer needs it.

If any check fails, act on it promptly and change the related passwords. If you find signs that someone already used the leaked details, such as unknown admin users or unfamiliar files, that’s the point to bring in a professional rather than cleaning up alone.

Why it helps to have an expert watching

None of these leftovers come from carelessness so much as from normal work: fixing an error, testing a redesign, making a quick backup before an edit. They pile up quietly over years, especially on DIY-hosted sites that have passed through several hands. For a small business in Juneau or anywhere in Southeast Alaska, the site is often busiest during the season when you have the least time to audit file folders.

That’s where a knowledgeable person makes a difference. Someone who knows where WordPress hides these files, cleans up after each project, and keeps staging copies locked down can prevent the problem rather than react to it. At Hoke Designs, we’ve been designing websites since 2007 and offer managed hosting alongside design and development, and existing clients can reach our support desk at support.hokedesigns.com with questions.

Key takeaways

• Attackers scan constantly for leftover files; millions of wp-config backup probes happen every month.
• Turn off WP_DEBUG on live sites and delete /wp-content/debug.log.
• Never keep copies of wp-config.php with extensions like .bak or .txt on the server, since they can be downloaded as plain text.
• Keep backups and .git folders out of public web directories.
• Password-protect staging sites, keep them updated, or delete them when the project ends.
• If anything was exposed, change the credentials and get expert help if you see signs of intrusion.

If you’d like a hand checking your site, call (424) 209-8199 or send a message via our contact form, and a person will reply within one business day.

Images are presented for illustration purposes only.We use real photographs when we need to show what was happening at a real event.