WordPress authentication keys and salts protect cookies and nonce-related values. Replacing them invalidates existing login cookies, but it does not change account passwords, remove application passwords or clean malicious code.
Rotate them after securing the configuration writer and plan for every user to sign in again.
Preserve configuration evidence
Before editing, snapshot wp-config.php structure, owner, permissions and relevant deployment history. Do not copy the secret values into tickets or repositories.
Check whether configuration comes from environment variables, a host template or secret manager; editing the deployed file may be overwritten later.
Record the authorised rotation time.
Secure hosting access first
Revoke unknown cPanel/Plesk/SFTP/SSH/deployment sessions and rotate control credentials from a clean device. An attacker who can write wp-config.php can replace new keys.
Review primary email and hosting recovery contacts, enable MFA and inspect sibling sites sharing the system user.
Do not rely on WordPress-only access for configuration recovery.
Generate fresh unique values
Use a trusted WordPress source or managed secret process to generate all authentication key/salt values. Do not reuse another site’s values or keep placeholders.
Update the correct production environment and avoid exposing secrets in shell history. Keep staging and production independent.
Coordinate multi-server deployments so all active nodes change together.
Understand session invalidation
Users should be logged out and required to authenticate again. Record expected business impact for customers, administrators and long-running checkout/account sessions.
If some sessions remain, check multiple servers, cache and whether they read different configuration. Do not restore old salts to avoid inconvenience.
Test canonical hostname and cookie scope.
Coordinate multiple application nodes
Load-balanced/container deployments must receive the same current keys at the same cutover. A stale node can accept/create incompatible cookies or restore old configuration.
Update the authoritative secret store/deployment, roll/restart nodes and verify no old instance serves traffic. Do not paste values into each server manually without audit.
Check object/cache/session services are separated by environment.
Revoke user sessions explicitly
Review administrator/shop-manager sessions and revoke all after compromise. Reset passwords and enable MFA for privileged owners.
Core session invalidation and salt rotation overlap, but explicit user review identifies unknown accounts/emails/roles and pending changes.
Do not delete ordinary customers without evidence.
Check non-WordPress sessions
Salt rotation does not revoke cPanel/Plesk, SFTP/SSH, database, primary-email, Cloudflare or payment sessions. Inventory and close those independently.
Likewise, OAuth tokens and webhook/API secrets may remain active after every WordPress user is logged out. Assign each to an owner and rotation record.
Do not use salt rotation as proof the attacker lost all access.
Review application passwords
Application passwords support API clients and may require separate revocation. Inventory token names, parent users and owners; revoke unknown or exposed credentials.
Replace legitimate integrations using dedicated least-privilege service accounts. Changing the normal user password is not a complete API-token inventory.
Monitor REST activity after rotation.
Rotate readable secrets
If an attacker read wp-config.php, rotate database, SMTP/API, backup and any embedded payment/webhook credentials. Issue replacements first, test, then revoke old values.
Move secrets out of themes/plugins/public repositories. Use one minimal credential per site/service.
Do not break business integrations without mapping dependencies.
Verify configuration integrity
Record a non-secret baseline/hash and alert on unexpected future changes. Inspect must-use plugins, cron and deployment jobs that can rewrite configuration.
Remove temporary access and confirm file permissions/ownership match hosting requirements. Do not make configuration immutable if normal deployment/rotation cannot update it safely.
Test backup restoration preserves intended secret sourcing.
Test normal operations
Verify administrator/customer login, logout, password reset, forms, checkout, REST integrations and scheduled jobs. Confirm unknown sessions/tokens no longer function.
Monitor privileged account/config changes after reopening. Document owner and rotation date without values.
Request urgent recovery when salts revert or environments disagree. Share file metadata and managed access—never keys, cookies, passwords or complete configuration publicly.