WordPress admin user added without your knowledge — how to detect privilege escalation

1. Problem

You open wp-admin/users.php for an unrelated reason and there is an Administrator account you did not create. Maybe it has been there for weeks. Maybe the username is close enough to your team's naming convention that it almost slipped past you: wp_admin2, support_staff, a display name that mimics a real colleague. Nobody on the team recognizes it, and nobody will admit to creating it.

If you searched "unknown wordpress admin user" or "new administrator account I didn't create," the standard advice is to delete it, change your own password, and move on. That ignores the two questions that matter: how did that account get administrator, and is it the only thing an attacker planted. A password change does nothing if the account itself was made specifically to survive one.

A new administrator you did not create is the single most common persistence move after a WordPress compromise: the attacker wants a login that survives you changing one password. It also happens for ordinary reasons: an agency onboarding a colleague, a plugin creating a service account. Telling those apart, and proving which happened, is the point of this guide.

The event surfaces as the wp_user_lifecycle_total signal, attributed to an actor and a time. This guide walks through reading that attribution and correlating it to decide whether you are looking at a backdoor or a Tuesday-afternoon onboarding.

2. Impact

A rogue administrator is a standing grant of full control that does not depend on any credential you already know to rotate. Every other fix you apply while that account exists is provisional.

• It defeats the fix you already did. Resetting your own password after a brute-force alert leaves the attacker's actual objective, an admin account only they know the password to, untouched. The intrusion looks resolved while the access point is still open.
• One administrator can mint more. The rogue account can sit quiet for months, then create a second admin or edit a theme file to add a webshell. The original is disposable once it has spawned a replacement.
• Administrator capability is the whole site. Plugin and theme editing, export tools, user management, payment gateway settings, all reachable from one login. There is no "limited damage" once this is granted to someone unauthorized.
• Misattribution wastes the response. Deleting an account that turns out to be a legitimate hire or a plugin's service account breaks a real workflow and teaches nobody anything about the actual incident, if there was one.

3. Why It’s Hard to Spot

WordPress treats every path to administrator identically once it is done. A row created by wp-admin/user-new.php from a logged-in admin looks exactly like one created by a script calling wp_create_user() against an exposed endpoint. The users table has no column for "how did this happen."

The users list screen works against you here. It sorts by registration date by default, burying a new row among legitimate accounts, and it shows a role name, not a role history. An account that registered as Subscriber last month and was quietly promoted to Administrator yesterday shows only "Administrator" today. The promotion itself leaves no trace in the UI at all.

Default email notifications do not help either. wp_new_user_notification() sends the new user their credentials, not you a warning, and a promotion sends no email at all. A managed host's dashboard shows "user count: 12" with no distinction between an intern who joined last week and an account that granted itself keys to the building.

The deeper problem: backdoor and onboarding produce an identical end state, one more row in wp_users with wp_capabilities set to administrator. What distinguishes them is everything happening around the event, none of it visible from the users screen.

4. Cause

The wp_user_lifecycle_total signal fires on user_register, profile_update, and delete_user, carrying an action label (created/updated/deleted), an actor label (anonymous/self/admin), and a role label. An unexpected administrator shows up one of two ways: brand new with the role attached at creation (action="created", role="administrator"), or an existing account promoted after the fact (action="updated", role="administrator"). Promotion also lands on wp_state_changes_total{change_type="user_role_added"}, the mirror image of the capability-loss pattern covered elsewhere: gaining a capability rather than losing one.

Because the signal is emitted from inside the request that performed the change, the actor label is the actual authenticated actor at that moment, not an inference. actor="admin" means an existing, valid session did this, narrowing the question to whether it was really that person at the keyboard. actor="anonymous" means no logged-in session was behind it, a much shorter list of explanations, most of them bad.

Each common path leaves its own fingerprint in the surrounding signals:

• Backdoor via a compromised admin session. An attacker with a valid admin cookie creates a new administrator as insurance before you close the original entry point. Shows as actor="admin" right after a wp_auth_attempts_total{result="success"} from an unfamiliar source_ip or ip_country.
• Backdoor via a vulnerable plugin or exposed endpoint. A plugin vulnerability, an unauthenticated REST route, or a direct call into wp_insert_user() creates the account with no session at all: actor="anonymous". Nothing in stock WordPress lets an anonymous request register as administrator.
• Backdoor via role promotion after the fact. A low-privilege account, created weeks earlier and left dormant, is quietly promoted: wp_state_changes_total{change_type="user_role_added"} on an account whose original created event is much older and shows a lower role.
• Legitimate onboarding, or a plugin's own service account. An expected admin session creates the account through the normal dashboard flow (actor="admin", no preceding auth anomaly), or a migration/staging/backup integration provisions its own admin-level account, clustering tightly with a wp_state_changes_total{change_type="plugin_activated"} event moments earlier, same actor, no gap.

The wp.state_change signal makes the correlation possible: it records plugin activations, role edits, and configuration writes on the same timeline as the lifecycle event. Read alone, a new administrator is a fact with no explanation. Read against wp.state_change and wp_auth_attempts_total, it usually has one.

5. Solution

5.1 Diagnose (logs first)

Do not delete the account before reading its history. Once it is gone, the timestamps, the actor label, and the surrounding correlation are much harder to reconstruct.

1. List every administrator and its registration date. Confirm which accounts exist and when each first appeared.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Any username you cannot account for goes to step 2 first.

2. Find the lifecycle event. You want the action, the actor, and the exact timestamp.

grep -nE "wp_user_lifecycle" /var/log/wp-audit.log \
  | grep -i "wp_admin2"

A typical entry:

[13-Jul-2026 03:41:07 UTC] wp_user_lifecycle_total{action="created", role="administrator", actor="anonymous"} user_login=wp_admin2 source_ip=185.220.101.47

Read it literally: action="created" plus role="administrator" means the account was born privileged, and actor="anonymous" means no session did this. Not an onboarding: escalate immediately.

3. Pin the timestamp and look both directions. Before, check for an auth anomaly or a plugin change. After, check whether the new account has logged in yet and from where.

# Auth activity and any plugin/config change in the half hour before
grep -nE "wp_auth_attempts|wp_state_change" /var/log/wp-audit.log \
  | awk '$1 >= "[13-Jul-2026 03:10" && $1 <= "[13-Jul-2026 03:45"'

# Has the new account logged in, and from where
grep -nE 'wp_auth_attempts.*result="success"' /var/log/wp-audit.log | grep "wp_admin2"

These checks form one timeline: wp_user_lifecycle_total anchors the moment, wp_auth_attempts_total shows whether a surge preceded it, and wp.state_change shows whether a plugin install or config write happened alongside it.

5.2 Root Causes

Match what diagnosis found to the cause before deciding how hard to respond.

• actor="anonymous" on a created event at administrator role means no legitimate session was behind it. Cause: a vulnerable endpoint or exposed function called directly.
• actor="admin" immediately after a wp_auth_attempts_total{result="success"} from an unfamiliar ip_country means a real session did this, but may not belong to the person it claims. Cause: account takeover, the new admin is the attacker's insurance policy.
• A wp_state_changes_total{change_type="user_role_added"} event on an account dormant for weeks or months means a promotion, not a creation. This is the pattern most likely to be missed, since the account is old news by the time it matters.
• actor="admin" with no preceding auth anomaly means an ordinary administrator did what the interface let them do (legitimate onboarding, verify and close it out), unless a plugin_activated event lands seconds earlier, same actor, in which case a plugin provisioned its own service account. Confirm the plugin was installed on purpose either way.

5.3 Fix

The response scales with section 5.2. Do not apply the full incident-response fix to a confirmed onboarding, and do not stop at "deleted the account" if the evidence points to a backdoor.

Confirm before you act. If the actor was admin and there is a plausible explanation, ask the team directly. A confirmed yes ends it. Do not assume malice on an account you have not asked about, or innocence on one you have.

If unconfirmed: remove it. Do not just delete the user; review its content first.

# Review its content, then remove (reassign to a known-safe user)
wp post list --author=$(wp user get wp_admin2 --field=ID) --post_status=any
wp user delete $(wp user get wp_admin2 --field=ID) --reassign=1

# Force reset every remaining administrator, not just the one you found
wp user reset-password $(wp user list --role=administrator --field=ID)

Rotate salts unconditionally. If the actor was ever admin on the creating event, treat a hijacked session as live. Generate a fresh set from https://api.wordpress.org/secret-key/1.1/salt/, replace the block in wp-config.php, and deploy. This invalidates every existing session, including the rogue account's.

Audit for other persistence. An attacker who plants a backdoor admin rarely stops there: check for malicious plugins (a slug not in the WordPress.org directory, activated at the same timestamp), unfamiliar additions to wp-config.php or .htaccess, and cron entries you did not schedule. See the wp-config modified guide and the file integrity guide.

Find the entry point. Removing the account without finding how it got there means it happens again. A preceding auth surge is covered in the auth-attempt surge guide; a preceding plugin activation in the plugin silently activated guide.

5.4 Verify

This is fixed when no further unexpected administrator events occur, not when the one account you found is gone. A single deletion confirms nothing about the entry point.

# Confirm the administrator list matches your known-good set
wp user list --role=administrator --fields=ID,user_login,user_registered

# Confirm no new privileged lifecycle events or role promotions since the fix
grep -nE 'wp_user_lifecycle.*role="administrator"|wp_state_changes.*user_role_added' \
  /var/log/wp-audit.log | awk '$1 > "[13-Jul-2026 04:30:00 UTC"'

Healthy state is a flat wp_user_lifecycle_total{role="administrator"} at your known admin count, last changed by your own confirmed cleanup. Watch for a full week: an attacker with a second entry point often tries again within days, and another event in that window means the entry point was never closed.

6. How to Catch This Early

Finding a rogue administrator is straightforward once you know to look. The hard part is that nothing tells you to look until the damage is done.

This issue surfaces as wp_user_lifecycle_total.

Default WordPress alerts nobody when a new administrator appears. There is no dashboard notice, no digest email, no distinction between an account created by a trusted teammate and one created by an anonymous request against a vulnerable endpoint. The actor, role, and timestamp exist together only in a log line most site owners never read.

A count of privileged account events, with the actor label attached, answers what the users screen cannot: did a real admin session create this, or did nothing authenticate first. It also surfaces the promotion case, the account that quietly went from Subscriber to Administrator with no new row appearing anywhere. Watching it alongside wp_auth_attempts_total and wp.state_change turns "we noticed an unfamiliar admin account" into "an administrator was created at 03:41 UTC by an anonymous request, thirty seconds after an unscheduled plugin activation." Reading this from the logs, rather than relying on someone scrolling to the bottom of the users list, turns discovery weeks later into a notification minutes after it happened.

7. Related Silent Failures

• wp_auth_attempts_total surge: a credential-stuffing or brute-force wave in the hours before a new administrator appears is usually the entry point, not a coincidence. Covered in the auth-attempt surge guide.
• wp_state_changes_total plugin_activated cluster: an unrecognized plugin activating right before the account appears, or provisioning one itself. See plugin silently activated.
• wp.state_change on wp-config.php: edited salts, a hidden include, or DISALLOW_FILE_EDIT flipped back off in the same session that created the account. See wp-config modified.
• wp_state_changes_total user_role_added on a dormant account, or wp_user_lifecycle_total actor="anonymous": a promotion with no matching creation nearby, or any lifecycle event with no authenticated session behind it at all, since stock WordPress has no legitimate path that produces either.