There's a New Admin User I Didn't Create

Why this one is different from the other symptoms

A lot of the "is my site hacked?" signals covered elsewhere on this site have an innocent explanation available. A slow site is usually bad hosting, not cryptomining. A weird redirect could be a caching bug before it's a malware injection. Those symptoms require investigation precisely because they're ambiguous.

An Administrator account in your Users list that nobody on your team created isn't ambiguous. WordPress doesn't spontaneously generate admin users, and a legitimate teammate doesn't forget they created one with full site access. If you're looking at a username you don't recognize, sitting at the Administrator role, this is one of the clearest single signals of an actual compromise you'll encounter — not a "maybe," a "yes."

Two things worth ruling out first

Before treating this as a confirmed compromise, it's worth being honest that a small number of legitimate explanations do exist, even if they're rare:

• A plugin's own setup process. Some plugins — particularly ones that integrate with an external service, or that ship a companion support tool — create a secondary account during activation for their own internal use. This is unusual and arguably bad practice on the plugin's part, but it isn't malicious. Check the plugin's own documentation or support channel if the account's username or email pattern matches a specific plugin you recently installed.
• A teammate or agency you forgot gave access. If you work with a developer, an agency, or a co-founder, confirm with them directly before assuming the worst. It's a five-minute message that can save you an afternoon of unnecessary incident response.

If neither of those explains it — and for most site owners, neither will — move forward as a real security incident.

This is not the same as a dormant admin account

It's worth being precise about what this article covers versus what it doesn't. A dormant admin account is an old, legitimate account — maybe a former employee, a past contractor, an account from a plugin's setup wizard — that's still sitting there with elevated access it no longer needs. It's a standing risk because it's an unwatched door, not because it was created maliciously.

What this article covers is the opposite situation: the moment you discover a brand-new account that was never legitimately created by anyone on your side in the first place. Different discovery, different urgency, same underlying theme — account hygiene is what makes both of these things visible before they become expensive.

How attackers actually do this

Rogue admin creation is a well-documented, actively-used persistence technique, not a rare edge case. Security researchers have tracked multiple real campaigns built specifically around it:

• Direct creation through a vulnerability. Some WordPress plugin vulnerabilities allow an attacker to create a new user directly — sometimes even through the REST API — without ever needing valid credentials in the first place.
• A "backup" account created after initial access. Once an attacker has admin-level access through any route — a leaked password, a compromised plugin, a webshell — one of their first moves is often to create a second, independent administrator account. If the original entry point gets patched or the compromised credential gets rotated, the backup account keeps their access alive.
• Disguised as a plugin. Sucuri has documented fake plugins, distributed as ordinary-looking ZIP files and installed through the normal plugin-upload flow, whose entire purpose is to silently create a hidden administrator account and then actively conceal it — in some documented cases even blocking attempts to delete the account from the dashboard, and phoning the new username and password home to an attacker-controlled server.

The throughline across all of these: a rogue admin account is rarely the whole story. It's usually a deliberate fallback an attacker planted specifically so that removing the obvious symptom doesn't remove their access.

The order that matters

The instinct is to delete the account immediately and move on. Resist that instinct until you've done a few things first — the same lesson that shows up elsewhere on this site with backup restoration: cleaning up the visible symptom without finding how it got there just means the attacker creates another one.

1. Don't delete it yet. Note the exact username, email address, registration date, and role before touching anything. This is your evidence trail if you need to investigate further or explain what happened to a client or stakeholder.
2. Check for a webshell first. Rogue account creation is frequently paired with a hidden backdoor script that can simply recreate the account (or a new one) the moment you remove it. Work through our webshell guide before you assume deleting the user is the end of the job.
3. Look for how it actually got in. Check recently modified plugins and themes, unfamiliar files, and any plugin you don't remember installing — especially one installed around the same date the rogue account appears.
4. Now remove the account — and immediately rotate every admin password and any API keys the site uses, since an attacker with admin access may have had time to see or copy them.

Full recovery and staying ahead of it next time

Once the account is gone and the entry point is closed, treat this the same way you'd treat any other confirmed compromise: work through our full malware removal guide rather than assuming the account was the only thing an attacker touched.

Going forward, the same account-hygiene habits covered in our dormant admin account guide and our privilege drift guide apply here too. If you keep a simple, current record of exactly who should hold Administrator access at any given time, a new name on that list stops being something you might not notice for weeks — it becomes something that stands out immediately.

A few habits make that record easy to maintain without turning it into a chore: review the full Users list on a fixed schedule rather than only when something feels wrong, sort by registration date occasionally so a new entry is obvious rather than buried alphabetically, and keep the number of Administrator-role accounts as small as the site's actual workflow allows — most contributors need Editor or a custom role, not full admin access. The fewer administrator accounts exist, the faster an extra one stands out.