What this problem looks like
WordPress ships eight authentication constants in wp-config.php. They should be unique per site. After malware or credential leaks, rotating salts invalidates hijacked sessions even if attackers know old passwords.
Changing keys does not delete users or content. Everyone must log in again, including API integrations that rely on application passwords or cookie auth.
Step 1: Generate fresh keys
Open https://api.wordpress.org/secret-key/1.1/salt/ in your browser. Copy the entire block of define statements. Each refresh produces unique random strings.
Step 2: Edit wp-config.php via SFTP
Locate the section labelled Authentication Unique Keys and Salts. Replace all eight lines with the new block. Do not leave duplicate define statements.
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' );
define( 'AUTH_SALT', 'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT', 'put your unique phrase here' );
define( 'NONCE_SALT', 'put your unique phrase here' );Step 3: Save and confirm the site loads
A syntax error in wp-config.php whitescreens the site. Save carefully and reload the homepage. You should see the site but be logged out of admin.
Step 4: Log in and review admin users
Go to Users → All Users. Delete unknown administrators. Force password resets for remaining admins. Check installed plugins for anything you did not add.
Step 5: Document the change for your team
Tell editors they must log in again. Reconnect integrations that used cookie-based auth. Application passwords in WordPress 5.6+ may need regeneration.
When to stop DIY and hire help
After a hack, rotating salts is one step in a full cleanup. BugShield removes malware, rotates credentials, and hardens wp-config at a fixed price through secure Vault access.