wp configphporig

📅 October 29, 2026📖 Verified Publication

```html wp-config.php.orig: What It Is, Why It Exists & How to Handle It Safely

`wp-config.php.orig`: The Complete Guide for WordPress Site Owners

Last updated: July 2026 · Reading time: ~12 minutes

Key Takeaways

wp-config.php.orig is an auto-generated backup of your WordPress configuration file, created by automated installers, staging plugins, or CI/CD deployment tools.
It can expose database credentials, authentication keys, and server paths if left in the web-accessible directory — making it a genuine security liability.
Always verify the source before deleting; confirm the active wp-config.php is working correctly first.
Best practice: move any .orig files outside the document root, encrypt sensitive credentials, and rotate them regularly.
Never commit wp-config.php or wp-config.php.orig to a public Git repository.

What Is `wp-config.php.orig`?

The file wp-config.php.orig is a timestamped or version-stamped backup of your active wp-config.php file. It is not something WordPress itself creates during a standard manual installation — it is generated by external tools that manipulate your configuration automatically.

Common sources include:

WP-CLI wptool phponly or one-click installer scripts that preserve the previous config before overwriting.
Staging-to-production sync plugins (e.g., WP Staging, Duplicator, All-in-One WP Migration) that write a backup before pushing changes.
CI/CD pipelines (GitHub Actions, GitLab CI, WP-CLI deploy hooks) that push environment-specific configs and keep the prior version as .orig.
Managed hosting auto-updaters that modify ABSPATH, table prefixes, or SSL constants before updating.
Security or optimization plugins that back up config before applying hardening rules.

The result is a near-identical copy of your wp-config.php sitting in the same directory, often with the exact same permissions.

Why It Matters: The Security Angle

Your wp-config.php contains the most sensitive data on any WordPress installation:

Data Exposed	Risk if Leaked	Common Placement
Database username & password	Full database compromise; data exfiltration	`DB_USER`, `DB_PASSWORD`
Authentication unique keys & salts	Session hijacking; cookie forgery	`AUTH_KEY`, `SECURE_AUTH_KEY`
Database host & name	SQL injection targeting via known host	`DB_HOST`, `DB_NAME`
Table prefix	Facilitates targeted SQL injection	`$table_prefix`
Abstract key paths / constants	Reveals filesystem structure	`WP_CONTENT_DIR`
Third-party API keys	Unauthorized use of paid services	Custom `define()` calls

If wp-config.php.orig is accessible via HTTP (which happens when .orig is not blocked by the web server), an attacker can request it directly and harvest all of the above without needing any WordPress credentials at all.

Sensitive File Editing Block Bypass

WordPress includes a DISALLOW_FILE_EDIT constant that blocks the Theme and Plugin Editor in the admin dashboard. However, it does not block direct file access. If your server serves .orig files, the editing restriction is irrelevant — the attacker reads the file through the browser, not through the editor.

Checklist: Audit Your `wp-config.php.orig` Situation

Phase 1 — Detection

[ ] SSH into your server or open FTP/SFTP access
[ ] Run: find /path/to/wordpress -name "*.orig" -type f
[ ] Check for wp-config.php.orig specifically in the root WordPress directory
[ ] Run: ls -la wp-config.php* to see all config-related files and their permissions
[ ] Verify whether your web server can serve .orig files by requesting https://yoursite.com/wp-config.php.orig in a browser
[ ] Search git history for committed .orig files: git log --all --full-history -- "*wp-config.php.orig*"

Phase 2 — Verification

[ ] Confirm your active wp-config.php is fully functional (visit your site, check admin panel)
[ ] Note the