criticalSeverity: criticalRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.Web server + DB credential rotationWhere it livesImplementationThis fix is applied in: Web server + DB credential rotation. That's the surface you'll edit, DNS, response headers, or a static file.~10 minTime to fixEffortRoughly 10 minutes of hands-on work, propagation aside. Most of these are copy-paste.+40 posture+40 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Exposed wp-config backup: rotate the DB login and clear the salts

Rotating your WordPress database credentials and salts, then removing the backup, closes a direct path into your site's data

The threat

Normally wp-config.php executes as PHP, so its contents are never served as text. A backup copy with a different extension is a different story. wp-config.php.bak, wp-config.php.save, wp-config.php~, or an editor swap file: the web server does not know to run those as PHP, so it hands them back as plain text. And wp-config is where WordPress keeps DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, and your authentication salts.

With the database username and password in hand, anyone who can reach your database host (many managed WordPress hosts expose one) can log straight in and read or change everything. The salts (AUTH_KEY and its siblings) sign your auth cookies, so once they leak, an attacker has the material to forge a logged-in session.

The exact fix

Step 1, contain: rotate the credentials this file exposed.

  • Change the WordPress database password (and username, if your host allows) in the database panel, then update the live wp-config.php with the new values.
  • Regenerate every salt. Replace the AUTH_KEY / SECURE_AUTH_KEY / LOGGED_IN_KEY / NONCE_KEY block (and the matching *_SALT lines) with a fresh set from the WordPress secret-key generator. This invalidates existing login cookies, which is what you want.
  • If any admin reused that database password elsewhere, change it there too.

Step 2, stop serving the backup.

  • Delete the backup file and any editor swap or save copies from the web root.
  • Stop making backups in place: edit config through a path that writes outside public_html, and do not leave .bak or .save copies behind.
  • Block the pattern at the server.

nginx:

location ~* wp-config\.php\.(bak|save|old|orig|swp|txt)$ { deny all; return 404; }
location ~* wp-config\.php~$                             { deny all; return 404; }

Apache:

<FilesMatch "^wp-config\.php(\.(bak|save|old|orig|swp|txt)|~)$">
    Require all denied
</FilesMatch>

Block the backup extensions site-wide while you are here. The same trick works against any config, so denying .bak, .save, .old, ~, and .swp everywhere means no editor leftover is ever served as text.

Verify it

curl -s https://yourdomain.com/wp-config.php.bak

Use the exact name from your report. You want a 404, not a page of PHP. If define( 'DB_PASSWORD' shows up in the output, the file is still exposed and the credentials still need rotating.

Proof

The ApeCyber scanner flags this passively with a single GET, from the outside, touching nothing. Confirmation is only that the file comes back as readable PHP, with no login and no contact with your database. At −40 this is the top single-finding weight, and it clears once the backup is gone and the credentials and salts are rotated.