wp-config.php stores the database credentials that let WordPress bootstrap normally. If an attacker deletes it, WordPress falls back into setup mode on the next visit, which allows a new database connection and administrator account to be configured. That turns a file operation into a complete compromise path, especially when the attacker already has edit or delete privileges.
Why a deleted wp-config.php changes the blast radius
WordPress treats wp-config.php as the bootstrap file that tells it which database to use and how to connect. If that file disappears, the application no longer has the information it needs to load the site normally, so it drops into its installation flow instead of failing closed. That is why a simple deletion bug can become a full site takeover when the attacker can reach the setup path.
The security consequence is not the deletion itself, but the fact that the deletion removes the trust anchor for the application state. Once WordPress believes it is not installed, it may allow the creation of new configuration values and a new administrator account, which effectively replaces the original control plane. At that point, the attacker is no longer just breaking availability, they are reinitialising ownership of the site.
How the bootstrap and setup flow create the compromise path
The dangerous part of this pattern is that the application’s installation logic is designed for first-time setup, not for hostile recovery scenarios. When wp-config.php is absent, WordPress can offer a wizard-like path that accepts fresh database settings and site metadata. If an attacker can supply those values, they can point the application at a database they control or create a new administrator context on the existing site.
This is a classic state-confusion problem. A file deletion primitive that should have caused a recoverable failure instead changes the application’s interpretation of reality. The attacker does not need code execution in the traditional sense if they can make the product believe it is in setup mode and then complete that setup with attacker-chosen values.
That is why the impact depends on adjacent privileges. If the delete action is limited to a harmless location, the issue stays contained. If the attacker can delete or replace the bootstrap file, tamper with webroot contents, or influence the installation route, the same bug can become a complete compromise path.
Why defenders should treat this as an access-control problem, not just a file-integrity bug
The practical lesson is that file deletion against a bootstrap or configuration file often carries privilege implications beyond the filesystem layer. A control failure that exposes wp-config.php can bypass the normal separation between content management and administrative control, because it targets the file that proves the site’s identity to itself.
For practitioners, the key question is whether the environment prevents an untrusted user from reaching any action that can delete, overwrite, or rename the configuration file. If that boundary is weak, the site is vulnerable to privilege escalation through application reinstallation, not merely to denial of service. Hardening the file permissions without protecting the full write path is usually insufficient.
Risk and Threat Considerations
This failure mode is attractive because it converts a low-visibility filesystem action into a high-impact trust reset. Attackers who can delete the config file can often chain that into new administrator creation, database reassignment, or persistent control of the site before defenders notice the original deletion event.
Failure mechanism: The application loses its bootstrap configuration, enters installation mode, and accepts attacker-controlled setup input instead of preserving the original site state.
Impact: The attacker can replace the site’s trusted configuration and administrative ownership, turning a single delete operation into full compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Config files and bootstrap secrets often function as authenticating material for the site. |
| AC-6 — Least Privilege | The exploit requires overly broad write or delete access to critical site files. | |
| CM-5 — Access Restrictions for Change | Preventing unauthorized modification of configuration files directly addresses this takeover path. | |
| Recommendation — Protect and rotate bootstrap credentials with tight lifecycle controls. Restrict file-system write permissions to the minimum necessary accounts. Require change controls for any action that can alter production configuration files. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | The compromise depends on protecting and controlling a critical application configuration file. |
| Recommendation — Control production configuration changes and protect critical files from unauthorized alteration. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | WordPress bootstrap integrity depends on hardened configuration and file permissions. |
| Recommendation — Harden file permissions and block unsafe write paths to the webroot. | ||
Practitioner Guidance
What to verify: Confirm that the web server, PHP process, deployment user, and any plugin or theme upload paths cannot delete or replace wp-config.php. Also verify that installation routes are blocked or strongly gated once the site is provisioned, especially in environments where content editors or integrations have filesystem-adjacent access.
Common mistake: Treating the issue as only a backup and restore concern. Backups help after compromise, but they do not reduce the blast radius if the site can be reinstalled by an attacker before detection.
Practitioner takeaway: If deleting one file can trigger a fresh trust establishment flow, you must protect that file as part of the site’s administrative boundary, not as ordinary content.
