Changing the WordPress administrator password is necessary in many incidents, but it may leave application passwords, login cookies, hosting access, database credentials and API keys active. Rotating everything without order can also break the site and encourage restoration of compromised configuration.
Base the scope on what the attacker could read or use.
Secure the recovery channel first
Use a known-clean device. Protect the owner’s email account, password manager and hosting account because they can reset other credentials.
Review email sessions, forwarding, recovery methods and app passwords. Enable multi-factor authentication where supported.
Do not generate clean secrets on a device suspected of credential-stealing malware.
Revoke WordPress sessions and tokens
Reset affected user passwords and remove unknown administrators. Generate new WordPress salts to invalidate existing login cookies.
Audit and revoke application passwords separately. They are not the same as the user’s primary password and can continue API access until removed.
Review SSO, membership and service accounts before disabling them; create replacement least-privilege credentials for legitimate integrations.
Rotate hosting and file access
Change control-panel passwords, revoke sessions and review authorised contacts. Replace FTP/SFTP/SSH users or keys that could reach the infected files.
Prefer individual encrypted access over shared FTP. Remove former contractor accounts.
If several sites share the account, assume credentials could expose all of them until isolation is proven.
Replace database credentials carefully
If wp-config.php could be read, create a new restricted database credential, update the clean configuration securely and verify the site connects. Then revoke the old user/password.
Do not expose the new secret in tickets, screenshots or shell history. Check backups and deployment configuration that may still contain the old value.
Use a distinct database user per application where hosting permits.
Review external API secrets
Inventory SMTP, payment, shipping, CRM, backup, CDN, DNS, analytics/tag-manager and webhook credentials stored in WordPress or configuration.
Prioritise keys exposed by the compromise scope. Rotate through the provider’s official console and test each integration in sandbox where possible.
For payment credentials or checkout injection, coordinate with the payment provider and incident/privacy process.
Remove old secrets from backups and automation
A rotated credential can remain in deployment variables, local configuration copies, support tickets and downloadable backups. Locate approved secret stores and update them before the next deployment.
Do not rewrite historical incident evidence casually; restrict and encrypt it, define retention, and ensure it cannot be restored directly to production. Rebuild scheduled backup jobs with the new access and test a restore into an isolated environment without exposing the replacement secrets.
Sequence rotation after persistence removal
Preserve evidence, contain malicious access and remove backdoors before entering new secrets into the server. Otherwise active code can steal replacements.
Some emergency revocations must happen immediately; document them and use a clean temporary maintenance environment.
Keep an owner/checklist so no secret is rotated twice while another critical one is missed.
Verify business functions
Test administrator login, password reset, scheduled publishing, backups, SMTP, forms, webhooks and authorised WooCommerce sandbox payment.
Monitor authentication logs for attempts using revoked accounts and tokens. Confirm no integration reintroduces the old credential from automation.
Record rotation dates and future owners without recording secret values.
Schedule a follow-up access review after all retained administrator sessions would normally have expired.
When access recovery needs coordination
Request help when many integrations share secrets, panel/email access is disputed or customer/payment data may be involved. Send the system inventory and timeline, never passwords.
A safe rotation restores clean control in dependency order and proves the site still operates without any old access path.