Active WordPress incident? Initial assessment within 4 hours. (Mon–Fri 8am–8pm, Sat 9am–2pm (CET/CEST))

Resources

Rotating WordPress secrets, salts, sessions, and API credentials

Sequence for rotating WordPress credentials

Rotate credentials after containment and from a trusted device. Secure hosting, registrar, email, and privileged identities first; revoke sessions and application passwords; then replace database, SFTP, and API secrets. Changing WordPress salts invalidates existing sessions. Every change needs an owner, secure delivery channel, dependency check, and functional test.

  • use a trusted administration device
  • inventory dependent integrations
  • distribute new secrets through a secure channel
  • prepare rollback and functional tests

Secure external control points first: registrar, hosting, central email, and identity accounts. Then address WordPress administrators, sessions, application passwords, database, SFTP/SSH, and external services. Replace salts in a controlled change to invalidate existing WordPress sessions.

Never copy secrets into logs or tickets

Store secrets in an appropriate credential manager. Record the service, owner, and rotation time, not the secret value.

Test forms, email, payments, backups, deployments, and monitoring. Delete credentials that are no longer needed rather than merely renaming them.

Which secrets may be affected?

The inventory extends beyond WordPress passwords: database credentials, hosting, SFTP/SSH and CDN tokens, SMTP settings, payment and fulfilment APIs, backup keys, deployment tokens, and webhook secrets. Executed PHP may read configuration or environment values; actual exposure depends on permissions and capability.

For each secret, assess whether it was reachable, what privileges it grants, and where it was reused. Reuse can extend the incident to another system.

Why does rotation order matter?

Secure identities that can reset other access first. Clean and harden the environment before placing replacement application credentials into it; surviving persistence could otherwise read them again.

Where an integration cannot change atomically, use a short controlled overlap: create the replacement, test it, and revoke the old value. Record the change window without recording the secret.

What does rotating WordPress salts do?

New salts invalidate existing WordPress cookie sessions. They do not automatically change user passwords, application passwords, or external API keys. Tell legitimate users to expect reauthentication and review privileged sessions afterwards.

The account review and hardening checklist add role review, MFA, logging, and scheduled review to the rotation process.

Sources

  1. OWASP Secrets Management Cheat Sheet
  2. WordPress: Application Passwords

Site affected? We assess it for free.