An unknown administrator is deleted, then returns with the same or a different username. Something still has permission to create users: malicious code, a scheduled callback, direct database access, compromised administrator session or an external identity/integration.
Deleting the account again is containment. Preserve creation evidence and identify the creator.
Record account details safely
Capture user ID, login, email domain, registration time, roles and relevant metadata. Do not attempt the account’s password or send it a reset email.
Record active sessions and application passwords through authorised WordPress tools where available. Preserve database and security logs before revoking access.
Avoid publishing usernames or email addresses; they can be stolen or belong to an impersonated person.
Remove immediate access
Terminate the unknown user’s sessions, revoke its application passwords and remove administrator capability through a controlled method. Reassign no content until you know whether posts were created maliciously.
If the site is actively changing, restrict administrator access or place it in a maintenance state. Keep at least one verified owner account through a secure recovery route.
Do not create a shared emergency administrator with a widely distributed password.
Identify the creation event
Search security logs, database audit data and web access around the registration time. Look for administrator actions, REST/XML-RPC calls, plugin endpoints and direct database changes.
WordPress hooks can log future authorised user creation with actor and request context, but add monitoring carefully and do not collect passwords or cookies.
If the account appears at a fixed interval, inspect cron and Action Scheduler.
Search code and database persistence
Review plugins, must-use plugins, themes, snippets and wp-config.php for user-creation functions, role changes and the recurring username/email. Analyse offline.
Inspect options and scheduled events for encoded callbacks. Check database triggers only where authorised; WordPress normally does not need custom triggers to create users.
Do not execute suspicious PHP to see whether it creates the account.
Check whether the user is only hidden from the interface
Compare the dashboard list with an authorised WP-CLI or direct read-only database inventory. Malicious code can filter pre_user_query, alter counts or hide one row without deleting it.
Review the users and usermeta relationship using the actual table prefix, and confirm every administrator role belongs to a known user ID. Do not edit serialised capability values directly on production. Preserve the hidden-row evidence, then remove filtering code before using ordinary WordPress user controls to revoke the account.
Review legitimate integrations
Single sign-on, membership, staging synchronisation or hosting tools can provision administrators. Confirm each integration’s owner and expected role mapping.
A legitimate integration can still be compromised. Review its account sessions, API keys and logs.
Disable one integration in staging for comparison rather than disconnecting production access without a recovery plan.
Rotate access at every relevant layer
Review all administrators, application passwords, hosting/SFTP/database accounts and deployment tokens. Rotate affected secrets after securing administrator devices.
Generate new WordPress salts to invalidate existing sessions. Coordinate external integrations so they receive new credentials securely.
Remove abandoned accounts and enforce individual access with least privilege.
Verify non-recurrence
Monitor user/role changes beyond the previous return interval. Trigger normal cron, backups and identity synchronisation.
Search for related malicious posts, options and files. Confirm verified administrators can still log in and password reset/email delivery works.
Review role counts daily during observation.
Request urgent assistance
Request malware cleanup when an administrator returns, role changes occur without an actor or external provisioning is unclear. Send timestamps and redacted account details, never passwords.
The repair should attribute account creation, revoke every persistence route and document verified administrative ownership.