An unexplained administrator is a confirmed access-control incident until proven otherwise. Deleting the user removes one account but does not explain how it was created or whether other access persists in files, database, hosting or email.
Preserve identifying evidence, contain the account and investigate the creation path.
Record the account before changing it
Capture user ID, username, email domain, registration date, role, metadata relevant to origin and any recent actions from protected logs. Note who discovered it and the exact time.
Do not email the unknown address or attempt to log in as the account. Avoid copying password hashes or personal data into tickets.
Take a database and log snapshot before removal where business risk permits.
Disable access safely
Block or remove the administrator capability and revoke its sessions/application passwords through a controlled administrator or database process. If active abuse is occurring, contain first and preserve the record immediately after.
Do not simply change the unknown account’s password; the attacker may have other sessions, keys or a way to recreate it.
Keep at least one verified owner account accessible from a clean device.
Audit legitimate creation paths
Confirm with site owners, developers, host and support providers that nobody created the account for maintenance. Review user-registration plugins, multisite super-admins, staging imports and automated provisioning.
An authorised account with poor documentation is still an access-governance problem, but it changes the incident scope.
Do not accept a familiar display name as proof of ownership.
Trace the creation event
Search web access, WordPress audit, PHP and control-panel logs around the registration timestamp. Look for user-creation API calls, administrator profile actions, vulnerable endpoints and database access.
IP addresses can be shared or proxied; correlate them with account, request path, session and file changes instead of treating an address alone as attribution.
Preserve logs before their retention window expires.
Review all privileged access
Inspect every WordPress administrator, application password and active session. Then check hosting users, SSH/SFTP keys, database users, deployment tokens, Cloudflare/DNS and primary email accounts.
Remove obsolete access and rotate credentials from a clean device. Enable multi-factor authentication where available.
Do not store new passwords in the same potentially compromised browser or shared document.
Search for account recreation
Malicious code can create an administrator on every request or scheduled event. Review must-use plugins, active theme bootstrap, wp-config.php, scheduled tasks and executable files in writable directories.
Compare core/plugins/themes with trusted sources and inspect recent changes. Do not rely only on the Users screen after deleting the account.
Monitor whether the user or role change reappears in a contained environment.
Check database privilege manipulation
An attacker may change user capabilities directly or hide accounts from normal admin queries. Review user and usermeta relationships, multisite roles and unusual filters that modify the administrator list.
Work from a database backup and use precise queries. Do not delete capability rows broadly, because legitimate owners can be locked out.
Record affected IDs rather than dumping all user data.
Close the initial access vector
Update or remove the vulnerable component, correct file permissions, secure exposed database/admin tools and revoke stolen credentials. If the vector is uncertain, rebuild from trusted code and import validated content.
Check whether the same credential or vulnerable plugin exists on sibling sites.
Reopening before persistence and entry path are addressed invites recurrence.
Verify and monitor
After recovery, confirm only approved privileged users, no unknown application passwords, clean scheduled tasks and expected file integrity. Test login, forms, checkout and email on the rebuilt site.
Alert on future administrator creation, role changes and new hosting keys. Retain the incident timeline under the organisation’s policy.
Request emergency rescue when the account returns, audit logs are missing or several control planes are involved. Share managed access and redacted identifiers—never password hashes, customer data or public backups.