In wp-config.php you find eight constants — AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and four matching salts. They are random encryption keys that WordPress uses when generating login cookies and nonces. Anyone who obtains the salts (for example, through a flaw that exposes wp-config.php) can forge an admin cookie. Rotating salts is basic hygiene and is the most important reactive step after a suspected compromise.
Why this matters
A WordPress login cookie is essentially a hash of username + expiration + a secret value derived from the salts. If an attacker gets the salts (a wp-config.php leak via a permissions flaw, a database read through a vulnerable plugin, or an unencrypted backup left in uploads), they can mint a forged auth cookie for any user without ever knowing the password. Even without a known leak, scheduled rotation is good practice: it invalidates every active session and forces a fresh login, capping the impact of a stolen cookie that "runs in the background".
How to detect
There is no direct check for "old salts". When the audit flags this item, it usually means it found default placeholder values ("put your unique phrase here") that were never changed during initial install. Inspect wp-config.php for the lines:
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');If you see the placeholder text, no unique salts were generated. Statistically this happens when a site was set up by manually copying a WordPress directory rather than running the installer.
How to fix
Step 1 — generate fresh salts: visit https://api.wordpress.org/secret-key/1.1/salt/. The page returns eight ready-to-paste lines.
Step 2 — copy all eight lines. In wp-config.php, find the existing block and replace the entire thing:
define('AUTH_KEY', 'X4#kP9mQ@vN2$wL8&rT6^eY3*hG7!fJ5...');
define('SECURE_AUTH_KEY', 'B8&jR3$pK7@nM2#wQ9*xL5^hF4!eT6%dS1...');
define('LOGGED_IN_KEY', 'D5*fG2!nP9$jM4@kT7&xL3^wQ8%bR1#vH6...');
define('NONCE_KEY', 'F1@hK4*nT9$mL6&xR2^pQ7!jB5%wD3#cV8...');
define('AUTH_SALT', 'G7&mP3$wK8@nT5*xL2^jR6!hF1%bD9#qV4...');
define('SECURE_AUTH_SALT', 'H2#vN6$pK9*mT4&wL7^xR1!jF8%bD5@cQ3...');
define('LOGGED_IN_SALT', 'J9!fT4$kP7@nL2*wM6^xR3&hB1%cV8#qD5...');
define('NONCE_SALT', 'K3*pR8$mN5@kT2&xL9^wQ6!jF1%bH4#vD7...');Step 3 — save the file. The moment you save, every logged-in user (including yourself) gets a 401 on the next request and must sign in again.
Common mistakes
Mistake one: hand-typing salts and reusing the same string for multiple constants. WordPress depends on entropy; identical salts reduce randomness and weaken cookie protection. Always use the wordpress.org API generator. Mistake two: stopping mid-rotation — only updating four of the eight salts. That leaves the site in an inconsistent state. Replace all eight together. Mistake three: rotating salts without warning the team. Every admin is logged out instantly; anyone editing a post at that moment loses their unsaved work. Coordinate, or do it outside business hours. Mistake four: relying only on salt rotation without addressing root cause. After a suspected compromise, salts are one step among several: also rotate database credentials, refresh plugins, and run a malware scan.
Verifying the fix
Reopen wp-config.php and confirm all eight lines are updated with 64-character random strings and that there are no duplicates. Browse to the site in a private window — you must be forced to log back in. After signing in, open DevTools > Application > Cookies and check the new wordpress_logged_in_* value — it must differ from the previous one.