Skip to content

wp_critical_file_modified

Severity: Critical Signal: wp.integrity — wp-config.php or .htaccess hash changed

What this signal means

The hash of a critical WordPress file changed since the last check. The plugin performs integrity checks on wp-config.php and .htaccess hourly. A hash change means the file content was modified.

What surprise this prevents

Malicious code injected into wp-config.php or .htaccess — redirecting traffic, exposing credentials, or enabling backdoors — without any visible indication to a casual observer.

Why it matters

These two files control your entire WordPress installation:

  • wp-config.php — database credentials, security keys, site URL, debug settings. Modification could expose credentials or introduce malicious configuration.
  • .htaccess — URL routing, PHP settings, access controls. Modification could redirect traffic, expose files, or disable security headers.

Unauthorized modification of either file is a serious security incident.

Investigate

View entity alerts in Logystera →

Check:

  • payload.file — which file changed?
  • When did the hash change? Correlate with any recent admin actions, plugin updates, or deployments.

Immediately compare the current file against your known-good backup or your last git commit.

Immediate:

  1. Download and review the changed file. Connect via FTP, SFTP, or SSH and open the file. Look for:
  2. Unknown database hosts or credentials.
  3. Added eval(), base64_decode(), or obfuscated code blocks.
  4. Added redirect rules in .htaccess (e.g. RewriteRule pointing to external domains).

  5. Added FilesMatch directives allowing PHP execution in upload directories.

  6. Restore from backup if you find unauthorized changes: bash # Replace with a known-good version cp wp-config.php.backup wp-config.php cp .htaccess.backup .htaccess

  7. Rotate all credentials in wp-config.php — database password, security keys and salts:

  8. Generate new salts at: https://api.wordpress.org/secret-key/1.1/salt/

  9. Update database password in both wp-config.php and your MySQL user.

  10. Scan for malware using Wordfence or Sucuri Scanner.

  11. Check server access logs for the time of the modification — look for unusual IP addresses accessing admin pages or file manager tools.

If the change was legitimate (you made a configuration change or a deployment updated the file), the alert is expected. The hash baseline updates automatically on the next check.

When to safely ignore

If you made a deliberate configuration change — updated a database credential, added a custom rewrite rule, deployed a code change — the alert is expected. The hash baseline updates automatically on the next integrity check.

Correlate the timing with your deployment logs to confirm the change was intentional.

Signal reference

{
  "event_type": "wp.integrity",
  "payload": {
    "type": "file_changed",
    "file": "wp-config.php",
    "previous_hash": "a1b2c3d4...",
    "current_hash": "e5f6a7b8..."
  }
}