Who could actually find a file like wp-config.php.bak?

Every scanner on the internet, within days. Bots request a fixed list of predictable names — wp-config.php.bak, .env, backup.zip, error.log — against every domain they see. Discoverability is not the barrier you might assume; a guessable name in a web-served directory should be treated as already found.

What is the actual exposure from a config backup?

wp-config.php contains the database credentials and authentication salts. A readable backup of it hands over database access (full content read and write, including password hashes) and the ability to forge login cookies. If such a file was public, assume the credentials in it are burned: rotate the DB password and salts, do not just delete the file.

How do I stop editors and backups creating these again?

Keep backups out of the web root entirely — a directory above it or off-server. Configure your web server to deny requests for *.bak, *.sql, *.log, and dotfiles as a safety net. Most of these files are created by an editor's save-a-copy habit or a backup plugin writing into the site directory; fix the tool's target once and the class disappears.

Glossary · Public files

A config, backup or log file is publicly accessible

Wordfence type: publiclyAccessible
Category: Public files
Severity: High to Critical depending on the file

A file that should never be reachable over HTTP returns a 200 to anyone who requests it.

Written by G. Schad, Cybersecurity Specialist Published 2026-07-31 · Updated 2026-08-22

The alert usually reads

Publicly accessible config, backup, or log file found: wp-config.php.bak

What Wordfence found

Wordfence requested the file over HTTP the way a visitor would and got a successful response. The finding names the path. Common cases are wp-config backups, .env files, SQL dumps and debug logs.

Why it matters

This needs no exploit at all. Anyone who guesses the filename downloads it, and automated scanners guess thousands of filenames a day across the whole internet. If the file contains database credentials or API keys, the compromise is complete and silent — nothing in the logs will look unusual.

How to fix it

1Delete the file. Editors that leave wp-config.php.bak or wp-config.old are the usual source.
2Assume anything it contained is exposed: rotate database credentials, API keys and salts.
3Block the pattern at the web server so a future deploy cannot re-expose it.
4Move backups out of the web root entirely rather than relying on obscurity.
5Re-request the URL yourself to confirm it now returns 403 or 404.

Common questions

Who could actually find a file like wp-config.php.bak?: Every scanner on the internet, within days. Bots request a fixed list of predictable names — wp-config.php.bak, .env, backup.zip, error.log — against every domain they see. Discoverability is not the barrier you might assume; a guessable name in a web-served directory should be treated as already found.
What is the actual exposure from a config backup?: wp-config.php contains the database credentials and authentication salts. A readable backup of it hands over database access (full content read and write, including password hashes) and the ability to forge login cookies. If such a file was public, assume the credentials in it are burned: rotate the DB password and salts, do not just delete the file.
How do I stop editors and backups creating these again?: Keep backups out of the web root entirely — a directory above it or off-server. Configure your web server to deny requests for *.bak, *.sql, *.log, and dotfiles as a safety net. Most of these files are created by an editor's save-a-copy habit or a backup plugin writing into the site directory; fix the tool's target once and the class disappears.

Findings that often appear with this one

wp-config.php is readable over the web Public files
A database backup is publicly accessible Public files

How WPSecureOps treats it

The connector reports this as publiclyAccessible. WPSecureOps files it under Public files and bands it by the numeric severity Wordfence assigns, so findings of this kind from every site you manage arrive in one queue rather than one email per site. Titles and descriptions are stripped of HTML and the site's absolute path is replaced before anything leaves the server.

Primary references

Product behaviour and remediation guidance were checked against these primary sources.