Home › Guides › Hidden Admin Users

Hidden Admin Users in WordPress: The Account You Didn't Create

By · Updated · 6 min read

If there's an administrator account on your WordPress site that you didn't create, your site has been compromised — that account was added by an attacker, and it will be used again. Worse, some rogue admins are rigged so they never appear on the Users screen at all, which means the dashboard can show two users while the database holds three. Removing the visible account is five minutes of work. Making sure there isn't an invisible one, and that the code that created it is gone, is the real job.

A rogue admin is one of the most common things I find on cleanups, and it's often the only piece of the compromise the owner ever noticed. Here's how they get there, how they hide, and how to remove them without leaving the door open.

How rogue admin accounts get created

Attackers rarely "hack your password" the way people imagine. Far more often, a vulnerable plugin or theme lets them run one small piece of code, and that code does something simple and devastating: it calls WordPress's own user functions to create a fresh administrator. Takes a fraction of a second. Some malware families create the account immediately; others plant a backdoor that creates one later, on demand, whenever the attacker needs interactive access.

The names are chosen to be skimmed past. I've removed accounts called admin2, wp-support, backup, root, and — my favorite — an account using the site owner's own first name with one letter doubled. The email addresses are throwaways or lookalikes of real ones. Registration dates get backdated so the account doesn't sort to the top as "newest."

Why some admins don't show on the Users screen

This is the part that surprises people. The Users list in your dashboard isn't a raw view of the database. It's a query, and queries can be filtered. Malicious code — usually a few lines dropped into a plugin file, a theme's functions.php, or the mu-plugins folder — can hook into that query and quietly exclude a specific username from the results. The same trick adjusts the user counts shown at the top of the screen, so the numbers still add up.

The effect: you can stare at your Users page every day and never see the attacker's account. The dashboard says 2 users. The database says 3. I check for this mismatch on every cleanup, because it's cheap for the attacker to set up and nearly invisible from inside the dashboard.

Checking the database directly

The only trustworthy view is the database itself. In phpMyAdmin (or whatever database tool your host provides), open the wp_users table — your prefix may differ from wp_ — and simply read the rows. Every account on the site is there, hidden or not. Then look at wp_usermeta for rows where the key is wp_capabilities and the value mentions administrator. That tells you exactly which accounts hold admin rights, regardless of what the dashboard displays.

Compare that list against the humans who should have access. Anything you can't account for is a finding. And if the dashboard count and the table count disagree, you've also just proven there's hiding code somewhere that needs to be found — a strong sign there's more to the infection, which is worth reading my indicators checklist for.

Application passwords: the quieter trick

Since WordPress 5.6, every user profile can carry application passwords — long tokens meant for connecting apps to your site through the REST API. Attackers love them, because an application password added to your own legitimate admin account gives them ongoing API access without creating any new user at all. Nothing new appears in the user table. The Users screen stays honest. And almost nobody ever scrolls down their own profile page to look.

So check: open each user's profile, scroll to the Application Passwords section, and revoke anything you don't recognize — or anything at all, if you don't use them on purpose. On sites that don't need the feature, I usually disable it outright.

Don't stop at administrators

Everyone audits the admin list. Fewer people look at the rest of the roles, and attackers know it. An editor account can publish posts and upload files, which is plenty for SEO spam. A shop-manager account on a WooCommerce site can see orders and customer details. And on sites with known privilege-escalation bugs in some plugin, a lowly subscriber account is just an admin that hasn't upgraded itself yet — attackers register a normal user through your own signup form, then wait for the right vulnerability to promote it. So the audit is every account, every role, against the list of humans you can name.

While you're at it, look hard at your own account. A trick I keep running into: the attacker doesn't add any user at all. They change the email address on the existing admin account to one they control, wait, and use the password-reset flow to take the account whenever they want it back. The dashboard shows the same usernames it always has. The only tell is an email address that's one letter off from yours, or a notification email about the change that went to spam. Check the address on file for every privileged account, not just the names.

Registration settings deserve thirty seconds too. If "Anyone can register" is on and you don't run memberships or a store, turn it off. I find it switched on surprisingly often on sites that never wanted open registration — sometimes flipped by malware, sometimes just left over from an old plugin's setup wizard.

Removing a rogue admin the right way

Deleting the account is the easy part, but order matters. Do it like this:

  • Delete the account from the Users screen (or the database if it's hidden), and when WordPress asks, attribute any content it owns to your real account rather than deleting posts blindly.
  • Change the passwords of every remaining account, starting with administrators.
  • Rotate the salts in wp-config.php so every existing login session dies immediately. The attacker may be logged in right now; this ends that session. My piece on wp-config.php after a hack walks through the rotation.
  • Revoke application passwords across all accounts.

Then the part people skip: find what created the account. A rogue admin is a symptom. Something put it there, and if that something is still on the site — a backdoor file, an injected snippet, a vulnerable plugin — the account will be recreated, sometimes within hours. I've had owners come to me after deleting the same intruder four times. The account was never the problem. The three lines of PHP in an abandoned plugin were. That hunt is its own discipline, and I've written up how I do it in WordPress backdoor removal.

If you want a quick outside read on your site first, my free scanner is a reasonable place to start. And if you'd rather hand the whole thing over — database audit, hidden-account check, backdoor hunt, session reset — that's a normal day for me. Here's how to get me on it.

Common questions

There's a WordPress admin user I didn't create. What does it mean?

It means your site was compromised. Attackers create administrator accounts through vulnerable plugins or planted code so they can log in like a normal user. Deleting the account isn't enough on its own — you also need to rotate passwords and salts, and find the code that created it, or it tends to come back.

Can a WordPress admin user be hidden from the Users screen?

Yes. The Users screen is a filtered query, and malicious code can hook into it to exclude a specific username and even correct the visible user counts. The account still exists and works normally. The only reliable check is reading the wp_users table directly in your database.

How do I find all administrators in the WordPress database?

Open your database in phpMyAdmin and read the wp_users table to see every account. Then check wp_usermeta for rows with the key wp_capabilities whose value includes 'administrator' — those are the accounts with admin rights, whether or not the dashboard shows them. Your table prefix may be something other than wp_.

What are application passwords and why do attackers use them?

Application passwords are API tokens attached to existing user profiles, built into WordPress since 5.6. An attacker who adds one to your real admin account gets ongoing remote access without creating any new user, so nothing looks out of place. Check each profile's Application Passwords section and revoke anything you don't recognize.

Why does the rogue admin account keep coming back after I delete it?

Because the code that created it is still on your site. Backdoors recreate their accounts automatically, sometimes within hours of deletion. Until that file or injected snippet is found and removed, deleting the account is cosmetic. The recurring account is your proof that a deeper cleanup is needed.

Should I change the salts after removing a rogue admin?

Yes. Rotating the salts in wp-config.php invalidates every login cookie on the site instantly, which ends any session the attacker still has open, including ones based on forged cookies. Everyone gets logged out and signs back in with their passwords. It costs you thirty seconds and closes a door most people forget exists.