An unfamiliar administrator is an obvious concern, but an attacker can also retain API access through an application password attached to a legitimate user. Removing one account does not revoke another user’s sessions or external credentials.
Build a verified access inventory before rotating everything.
Establish the rightful owner list
Ask the business to name current staff, developers, agencies and integrations. Record the intended role and last expected use for each account.
Compare this list with WordPress users, roles and registration dates through the dashboard plus an independent authorised method such as WP-CLI or read-only database review.
Malicious code can hide users from the dashboard, so interface counts are not sufficient.
Review role capabilities
Inspect users with administrator or equivalent capabilities, including custom roles. Check user meta for unexpected capability changes.
Do not rely only on the displayed role label. A modified role can grant plugin installation, user management or code editing under an innocent name.
Export role configuration before restoring known defaults; membership and ecommerce plugins may define legitimate custom capabilities.
Audit application passwords
WordPress application passwords allow API authentication without revealing the main password. Review every application password’s name, creation and last-used details where available.
Revoke unknown or obsolete entries. For a legitimate integration, create a new purpose-named credential after the site is clean and store it securely.
Never ask a user to send an application password through email or a contact form.
Terminate sessions deliberately
Generate new WordPress salts after preserving access evidence to invalidate existing login cookies. Reset passwords for affected administrators from clean devices.
Use individual accounts rather than a shared administrator. Remove abandoned users after reassigning legitimate content to a verified owner.
Coordinate service accounts so scheduled publishing or integrations do not silently fail.
Check how access was created
Review security/audit logs, web requests, SSO provisioning, plugin endpoints, database access and hosting sessions around user registration or password creation.
Search quarantined code and cron for user-creation or capability-change functions. Inspect vulnerable plugins that exposed account-management actions.
An email account used for password reset may also be compromised; secure its sessions, forwarding and recovery methods.
Validate administrator email ownership
Confirm each privileged account’s email through an independent business contact, not by writing to the address stored in the possibly compromised database. An attacker may have changed a legitimate username’s email while leaving the display name intact.
Review recent password-reset and user-email-change notifications in the site mailbox. Restore the verified address, then send a controlled reset only after sessions and application passwords are revoked. Check that SMTP logs do not expose reset links or forward them to unknown recipients.
Review API and XML-RPC activity
Look for unusual REST API or XML-RPC authentication associated with the user. Do not disable entire APIs without checking mobile apps, publishing tools or WooCommerce integrations.
Restrict access through supported controls and least privilege. Application passwords inherit the user’s permissions, so a dedicated low-privilege integration account is safer than attaching them to an owner administrator.
Verify after revocation
Monitor user creation, role changes, logins and application-password use beyond the incident window. Trigger normal SSO/integration synchronisation and confirm it does not recreate removed access.
Test verified administrator login, password reset and required publishing/API workflows. Document owners and review dates.
Re-audit after the next deployment.
When urgent access recovery is needed
Request help when users are hidden, administrators reappear or application-password activity is unexplained. Send timestamps and redacted user IDs—not credentials.
A complete access cleanup revokes sessions and tokens, attributes creation and removes the code or account route that granted them.