A wp-config.php Backup File Is Public—How to Contain the WordPress Credential Leak

5 hours ago

7 min read

A file named wp-config.php.bak, wp-config.php.old, wp-config.php~, or a similar copy appears under your public website address. This is not a harmless SEO oddity. A backup extension can cause the server to deliver the file as plain text instead of executing it, potentially exposing database credentials, security keys, environment values, table prefixes, and service tokens.

The correct response is containment first, credential rotation second, investigation third, and search cleanup last. Removing a Google result without removing the live file does not secure the website. Adding noindex or robots.txt is also not a substitute for deleting the exposed artifact.

This guide explains a cautious WordPress recovery workflow for site owners and developers. Do not paste the file contents, passwords, keys, or access logs containing personal data into public scanners, tickets, or chat messages.

First, Confirm the Exposure Without Revealing the Secret

Verify the exact URL from a private browser session or a command-line header request that does not print the response body. Record the status code, content type, date, and whether a CDN or cache serves it. Do not open or share the contents more than necessary.

A 200 response with downloadable or readable configuration content is an active exposure.
A 403 response blocks access but can still reveal that the file exists; deletion is safer for an accidental backup.
A 404 or 410 after removal is the desired public result.
A custom “not found” page returning 200 is not a real removal; confirm the HTTP status.
A CDN may continue serving a deleted origin file until its cached object is purged.

If a search query such as inurl:wp-config.php.bak finds a URL, treat it as a candidate until verified. Search results, security scanners, and server logs can produce false positives, but a positive live response requires immediate action.

Why a Backup Copy Is More Dangerous Than the Real PHP File

The live wp-config.php file is normally processed by PHP, so its source is not sent to visitors. A renamed copy may no longer be handled as PHP. The web server can return the source as text or a download.

WordPress documents that wp-config.php contains the site’s base configuration, including database connection information. It also contains authentication keys and salts used to strengthen cookies. OWASP warns that old, renamed, and backup files can expose credentials and internal paths because servers may serve them as plain source.

Assume disclosure based on what the file contained when the copy was made—not only what the current wp-config.php contains. An old database password or API token may still work.

Immediate Containment: Remove Every Public Copy

Delete the exposed backup from the web-accessible directory. Do not rename it to another predictable extension such as .old, .save, .copy, .txt, or a date-stamped filename. Move legitimate backups to storage that the web server cannot serve, or use a managed backup system with authenticated access.

Search the web root and deployment output for alternate copies, editor swap files, archives, database dumps, debug logs, and environment files.
Check the document root, WordPress root, parent directories that are publicly mapped, staging folders, and CDN origin storage.
Purge the exact URL from page cache, server cache, CDN, proxy, and object storage.
Confirm the public URL returns a genuine 404 or 410 from multiple networks.
Preserve a private forensic copy only if incident investigation or legal obligations require it.

If the site recently migrated, inspect the migration archive and staging environment too. Webcurry’s staging-site indexing recovery guide explains how forgotten copies can remain discoverable after launch.

Rotate Credentials—Deletion Alone Is Not Enough

Once a secret has been public, you cannot prove nobody copied it. Rotate every credential or token present in the exposed version. Use the hosting control panel or provider-approved process, and keep a rollback plan so the site is not left offline.

Database credentials

Create or assign a new database password, update the protected wp-config.php through a secure channel, and test the site immediately. If possible, restrict the database user to the necessary database and permissions. A temporary database-connection error during rotation should be resolved deliberately; use Webcurry’s database connection diagnostic rather than restoring the leaked password.

WordPress authentication keys and salts

Generate new WordPress keys and salts from the official service and replace the old values. WordPress documents that changing them invalidates existing cookies, which signs users out. That is desirable after potential disclosure.

Service and application secrets

Rotate any SMTP password, API token, payment webhook secret, object-storage credential, third-party integration key, or environment value present in the file. Revoke the old value rather than merely creating another active key.

Hosting and administrator access

The file may not contain WordPress administrator or hosting passwords, so do not rotate unrelated credentials blindly. However, if logs show suspicious access or credentials were reused, reset them and enforce multifactor authentication.

Review Access and Change History

Determine when the backup became public and who may have requested it. Review web-server, CDN, WAF, hosting, deployment, and security-plugin logs for the exact path and variants. Preserve timestamps and request identifiers, but avoid copying full IP or customer data into unsecured notes.

First and last request times for the exposed URL.
Successful 200 responses versus blocked or missing responses.
Unusual downloads, repeated filename variations, or automated scanning patterns.
Database logins from unexpected networks after the exposure began.
New WordPress users, changed administrator emails, plugin installations, file modifications, or scheduled tasks.
Changes to payment, SMTP, DNS, redirect, or analytics settings.

Absence of a logged request does not prove the file was never downloaded; logs may be incomplete or already rotated. Use the evidence to decide whether the incident requires hosting support, a security specialist, customer notification, or legal review.

Check WordPress Integrity

After credentials are rotated, compare WordPress core files with a trusted release, review plugins and themes, remove unknown administrators, scan uploads for executable files, and inspect scheduled tasks and must-use plugins. Update WordPress, plugins, and themes after preserving the evidence needed for investigation.

If core files must be replaced, follow Webcurry’s safe WordPress reinstallation guide. Reinstalling core does not rotate leaked credentials or remove malicious database entries, so it is only one part of recovery.

Protect the Real wp-config.php

WordPress’s hardening guide recommends limiting who can read wp-config.php and describes server rules that deny web access. It also notes that the file can be placed one directory above the WordPress installation in supported layouts, but warns that moving it carelessly can introduce risk.

Use the hosting platform’s recommended ownership and permissions. Do not apply 777 permissions. WordPress documentation gives stricter examples for wp-config.php, but the correct setting depends on the web server, PHP handler, deployment user, and hosting architecture.

A deny rule is defense in depth, not permission to keep backups in the document root. Confirm that the rule protects likely variants and works at every origin; then remove unintended files anyway. Webcurry’s WordPress 403 diagnostic can help distinguish an intentional security block from a broader access failure.

Remove the URL from Google Correctly

Only start search cleanup after the live file and cached origin copies are gone. Google’s guidance for exposed sensitive material is to remove the live document first, then use the Removals tool for the verified property to hide it quickly while Google recrawls the permanent removal.

Submit the exact exposed URL in Search Console’s Removals tool.
Submit additional URL variants only when they genuinely resolve to the sensitive content.
Keep the server returning 404 or 410 so removal becomes permanent after the temporary request expires.
Do not block the URL only in robots.txt; Google may be unable to recrawl and confirm that it is gone.
Do not rely on noindex inside a file that should never be publicly accessible.
Request outdated-content updates for copies hosted on systems you do not control after asking those hosts to remove them.

Google states that temporary removals expire after roughly six months. The server-side deletion is what makes the removal permanent. Search Console acceptance does not mean every search engine, archive, cache, or third party has deleted a copied secret—which is why credential rotation is essential.

Find Out How the Backup Entered the Web Root

A hosting file editor automatically created a .bak or tilde-suffixed copy.
A developer renamed the file before editing it in production.
A migration plugin extracted an archive into a public directory.
A deployment package included local backups, environment files, or database dumps.
A support technician saved a troubleshooting copy and forgot to remove it.
A staging or old-site folder was left accessible under the primary domain.
A server snapshot or object-storage bucket was made public.

Fix the workflow, not just this file. Prohibit in-place production editing where possible, exclude secrets and backups from deployment artifacts, add automated checks for dangerous filenames, and store backups outside served directories. OWASP specifically recommends preventing obsolete and unreferenced files from accumulating under web-accessible trees.

A Practical Verification Checklist

The exposed file and all known variants return genuine 404 or 410 responses.
Origin, CDN, proxy, page cache, and object-storage copies are cleared.
Database credentials from the exposed version no longer work.
WordPress keys and salts have been replaced and old sessions invalidated.
Every third-party secret present in the file has been revoked or rotated.
Administrator accounts, plugins, files, scheduled tasks, and logs have been reviewed.
The protected wp-config.php follows hosting-specific permissions and access controls.
Search removal was requested only after permanent server-side removal.
Deployment and backup procedures now prevent public copies.

Do Not Make These Mistakes

Do not publish a screenshot or paste of the exposed file while asking for help.
Do not assume deleting the Google result rotates the secrets.
Do not keep the backup under a less obvious public filename.
Do not use robots.txt as a security boundary.
Do not issue an indiscriminate database restore that destroys evidence or recent data.
Do not set broad 777 permissions to solve a file-access problem.
Do not declare the incident closed after one clean malware scan.

The Recovery Principle

An exposed wp-config.php backup is a credential incident, not merely a broken URL. Remove every public copy, revoke what may have leaked, verify the site’s integrity, and make the URL permanently unavailable before cleaning up search results.

If you need an evidence-based WordPress security review, contact Webcurry. Share the affected URL, timestamps, status codes, hosting architecture, and redacted log summaries—never the configuration contents or active credentials.

Authoritative References

WordPress Developer Resources: Hardening WordPress; Editing wp-config.php; Changing File Permissions.
OWASP Web Security Testing Guide: Review Old, Backup and Unreferenced Files for Sensitive Information.
Google Search Central: Keep Redacted Information out of Google; Remove Your Site Info from Google.