Skip to content

Unknown admin user in WordPress: what it means and how to remove it properly

An administrator nobody created means someone had the power to make one. Deleting it removes the symptom and leaves the way in. Rule out the innocent explanations, list every account from the database, record what you find, then remove it while you close the hole.

By
WP Ministry
Published

In short

  • Ask everyone with access before anything else. A developer, your host or a support plugin may have made the account.
  • In Settings, General, "Anyone can register" with "New User Default Role" set to Administrator makes every sign-up an administrator.
  • Do not rely on the Users screen. List the administrators from the database, where code on the site cannot hide one.
  • Write down the account's ID, login, email, registration date and sessions before you delete it. Deleting it erases them.
  • Deleting the account is one step. Reset every administrator's password, replace the secret keys and remove application passwords you do not recognize.
  • If the account comes back, something on the server is recreating it, and the site needs a full cleanup.

An administrator account that nobody on your side created means someone had the power to create one. Do not just delete it. Deleting the account removes the symptom, leaves the way in, and erases the record of when the account was made and where it logged in from.

Check whether anyone can account for it. If nobody can, list every administrator from outside the dashboard, write down what you find, and remove the account as one step in closing the hole.

Rule out the innocent explanations first

An unfamiliar name is not always an intruder. Four checks take a few minutes.

  • Ask everyone who has access. A colleague, a developer or an agency may have added it. Ask in writing, and wait for every answer.
  • Ask your host. Some hosts keep an account of their own on the sites they host. Pressable, for one, documents a built-in user named pressable, pressable_support or zippykid that only its staff can log in to. A name that looks like your host's proves nothing, so have the host confirm it.
  • Look for a support-access plugin. Plugins such as Temporary Login Without Password exist to create a temporary account, with any role, for a developer or a support agent. If a plugin's or a theme's support team asked for access recently, the account may be theirs.
  • Read the registration settings. In the dashboard, open Settings, then General. Under "Membership" there is one checkbox, "Anyone can register", and below it a drop-down, "New User Default Role". A new WordPress site has registration switched off and the default role set to Subscriber.

If "Anyone can register" is checked and "New User Default Role" says Administrator, every person or bot who fills in the registration form becomes an administrator. The safe values are "Anyone can register" unchecked unless the site needs visitors to sign up, and "New User Default Role" at Subscriber, which WordPress describes as somebody who can only manage their profile. Correct the setting now. It explains the account without making it innocent: something set it that way, and every account created while it stood needs checking.

You may have arrived here from an email. When a user registers, or is added in the dashboard, WordPress writes to the "Administration Email Address" with the subject "[Your site's title] New User Registration", the username and the email address. It does not say what role the account has. Look the account up in the next section.

If someone claims the account, confirm that the email address on it is theirs and you are done. If nobody does, carry on.

Find every account, including hidden ones

On a site that may be compromised, the Users screen is not a complete record. WordPress builds that table from a user query, and it lets any plugin or theme code change the query before it runs. Code planted on a site can use that to leave one account out of the table.

So list the administrators twice more: with WP-CLI, and straight from the database. How to use WP-CLI to manage WordPress covers getting set up. The database query needs neither SSH nor WP-CLI.

  1. Step 1: List the administrators with WP-CLI

    wp user list runs the same kind of query as the Users screen, so tell it to leave the plugins and the theme out. WP-CLI still loads files in wp-content/mu-plugins, which is why the next step exists. The user_registered column is in UTC.

    bash
    wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themes

  2. Step 2: List them straight from the database

    This query does not go through WordPress, so no plugin, theme or must-use file can alter the answer. Run it in phpMyAdmin or the database tool in your hosting control panel. With WP-CLI, save it as admins.sql and run wp db query < admins.sql.

    wp_ is the default table prefix, and yours may differ. wp config get table_prefix prints it, and so does the $table_prefix line in wp-config.php. The prefix appears in three places in the query: the two table names and the key. With a prefix of abc_ they become abc_users, abc_usermeta and abc_capabilities. The key is the one people miss, and with the wrong key the query returns no rows.

    sql
    SELECT u.ID, u.user_login, u.user_email, u.user_registered, m.meta_value
FROM wp_users AS u
INNER JOIN wp_usermeta AS m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%'
ORDER BY u.ID;

  3. Step 3: Compare the lists

    Every account in the database result should also be on the Users screen and in the WP-CLI list. One that is missing from either is being hidden by code on the site, and that is a break-in whatever the account is called. Stop here and follow the runbook for a hacked site.

    Read the whole user list too. WordPress allows capabilities to be added to another role, so an account can hold an administrator's powers without the name. Remove --role=administrator from the command and add roles to its --fields, or remove the LIKE line from the query, and account for every row above Subscriber. The query's last column is the account's stored capabilities, and it is the one to trust: a power granted to a single account directly, such as manage_options on a subscriber, shows there and does not show in WP-CLI's roles column.

  4. Step 4: On multisite, list the super admins

    On a network, a super admin has access to the network's administration and to all other features. Each site in a network also keeps its own roles under its own key: for site 2 with the default prefix, wp_2_capabilities.

    bash
    wp super-admin list --skip-plugins --skip-themes

Record it before you remove it

Deleting a user also deletes the user's metadata, and that is where WordPress keeps the account's login sessions. Take the record first.

  1. Step 1: Write down the account's details

    Copy the ID, the login, the email address and the registration date, and save the query's result as a file or a screenshot. The examples below use 123 for the unknown account's ID.

  2. Step 2: List its sessions

    Each row is one login by that account: when it logged in, when the session expires, the IP address and the browser's user agent string. Copy all of it. You will search the access log for these addresses.

    bash
    wp user session list 123 --skip-plugins --skip-themes

  3. Step 3: List what it published

    This shows the posts the account is the author of. Add --post_type=page for pages. You decide what happens to them when you delete the account.

    bash
    wp post list --author=123 --skip-plugins --skip-themes

Look in the access log for how it was made

Ask your host for the access log covering the day the account was registered, and ask today: a log reaches back only as far as the host keeps it. In Apache's format, each line holds the visitor's address, the time with its offset from UTC, the request and the status code. The registration date is in UTC, so convert it to the log's offset first.

The first pattern below is a day and an hour as Apache writes them. Set it to the hour the account was registered, then try the hours either side.

bash
grep "07/Oct/2026:14:" access.log | grep -E "wp-login\.php|user-new\.php|users\.php\?update=add|admin-ajax\.php|/wp-json/|rest_route=|xmlrpc\.php"
What the log shows at that timeWhat it points to
POST /wp-admin/user-new.php, then GET /wp-admin/users.php?update=add&id=123On a single site, the account was added on the dashboard's Add New User screen by someone already logged in and allowed to create users. The number after id= is the new account's ID. An existing administrator's login was used.
POST /wp-login.php?action=register, then GET /wp-login.php?checkemail=registeredSomeone used the public registration form. That makes an administrator only if the default role was Administrator at that moment.
POST /wp-json/wp/v2/users answered with 201WordPress's REST API created the account. WordPress allows that only for a caller who has authenticated and may create users, for example with an administrator's application password.
POST /wp-admin/admin-ajax.php, or a POST to a plugin's own route under /wp-json/, from an address that never logged inA plugin handled the request. Plugins can register actions on admin-ajax.php that answer visitors who are not logged in. This fits a vulnerable plugin and does not prove one.
NothingThe account was created by code already on the server, or written into the database, or its date is not real.

Be careful with what you conclude.

  • The log gives an address, a time and a request. WordPress's hardening guide notes that logs will not tell you which username logged in. An access log line holds the request line and not what a POST carried, so it cannot show which action a plugin was asked to perform.
  • The registration date is a value like any other. Whoever creates an account in code can set it. A date years in the past, on an account nobody remembers, is not reassurance.
  • How the account was made is not how they first got in. If the dashboard was used, the question becomes how they came to hold an administrator's login.

Then search the whole log for each address you recorded, with grep "^203.0.113.5 " access.log, to see what else it requested. The ^ and the space keep it from also matching 203.0.113.50.

How an unknown administrator gets there

  • A stolen or guessed administrator password. WordPress's hardening guide names password guessing as one of the two most common kinds of attack, and its FAQ for hacked sites says many break-ins begin on the owner's own computer, where malware captures logins. Anyone logged in as an administrator can add another. See how to protect WordPress from brute force attacks.
  • A vulnerable plugin or theme. The other common kind, in the same guide, is a request crafted for a specific vulnerability, often in an outdated plugin. The class that produces this symptom is code that performs a privileged action without checking who is asking. WordPress's plugin handbook shows a missing capability check that lets any visitor trash posts. When the unchecked action creates a user or saves a setting, a visitor needs no password at all. One public example: in July 2023 the developers of the Ultimate Member plugin reported that versions before 2.6.7 let attackers inject an administrator account, and the entry in the National Vulnerability Database, CVE-2023-3460, says it was being exploited at the time. Their advice to site owners included reviewing every administrator and deleting the unknown ones.
  • Open registration with a privileged default role. The two settings described above. They can be set by anyone with an administrator's login, or through a plugin flaw that lets a request save settings.
  • A backdoor file that recreates the user. The hardening guide warns that an attacker with an administrator's access can install malicious scripts. Code running on the server needs no dashboard: WordPress's own functions create users, and a file in wp-content/mu-plugins runs on every request without appearing in the main list of plugins. Code like that can make the account again each time it runs.

Remove it properly

  1. Step 1: Delete the account

    Here 123 is the unknown account and 1 is your own. --reassign gives the deleted account's posts and links to the user you name. Without it, WP-CLI asks you to confirm and then moves all of the account's posts to the Trash. Reassign only content you have looked at and want to keep, and first delete anything it published that you did not write, so that it does not become yours. In the dashboard, Delete on the Users screen asks the same question. On multisite the command removes the user from the current site only. To delete the account from the whole network, first take away super admin status if it has it, with wp super-admin remove <login>, then run wp user delete 123 --network --yes. Content cannot be reassigned on a network, so the account's posts go with it: look at them first.

    bash
    wp user delete 123 --reassign=1 --skip-plugins --skip-themes

  2. Step 2: Reset every administrator's password

    Check the email address on each real administrator first, because a reset link goes to that address. The command gives every administrator, you included, a new random password and sends no email. Tell each person to set their own through "Lost your password?" on the login page. If the site's email is unreliable, replace --skip-email with --show-password to print the new passwords. If the log pointed to a stolen login, or you cannot tell, change the hosting, SFTP and database passwords as well. How to remove malware from a hacked WordPress site has the order.

    bash
    wp user reset-password $(wp user list --role=administrator --format=ids --skip-plugins --skip-themes) --skip-email --skip-plugins --skip-themes

  3. Step 3: Replace the secret keys

    WordPress's FAQ for hacked sites gives this as the way to force off anyone who is still logged in, which includes an account you have not found. The salt generator makes a fresh set of eight lines in your browser. Paste them over the matching eight in wp-config.php, or let WP-CLI do it. Everyone logs in again, you included. Nothing else changes.

    bash
    wp config shuffle-salts

  4. Step 4: Remove application passwords you do not recognize

    An application password lets a program act as a user through the REST API. It is separate from the account's main password, and WordPress's documentation describes revoking each one individually, so do not count on a password reset or new keys to remove one. Run this for each administrator's ID and look at the name, the date created and the last address that used it. The dates are printed as Unix timestamps, and date -u -d @1791390665 turns one into a date. Delete one with wp user application-password delete 1 <uuid>, or under "Application Passwords" on the user's profile screen.

    bash
    wp user application-password list 1 --fields=uuid,name,created,last_used,last_ip --skip-plugins --skip-themes

  5. Step 5: Check the plugins, including must-use plugins

    Read the Plugins screen for anything you did not install. Then list the must-use plugins. They are switched on automatically, they are left out of the main list and shown in a separate Must-Use section, and they cannot be deactivated, only removed by deleting the file. Hosts commonly put their own files there, so ask your host about any you cannot place before deleting it.

    bash
    wp plugin list --status=must-use --skip-plugins --skip-themes

  6. Step 6: Verify the checksums

    This compares WordPress's own files with the checksums WordPress.org holds for your version, without loading WordPress. wp plugin verify-checksums --all --skip-plugins --skip-themes does the same for plugins from WordPress.org. How to check whether your WordPress site has been hacked explains how to read the results and what they do not cover.

    bash
    wp core verify-checksums

  7. Step 7: Update everything and close the route you found

    Update WordPress, every plugin and every theme, and delete the plugins you do not use. How to safely update WordPress has the order. Turn on two-factor authentication for every administrator. If you could not find the route, a security audit is the next place to look.

Run the database query again the next day, and again a week later.

If it comes back

If the account returns, or a different one appears, something on the server is recreating it: a file you have not found, or the same hole, still open. Deleting it again changes nothing. From here the job is a full cleanup. Follow the runbook for a hacked site for the first hour, then the malware removal guide.

Get help when:

  • the account comes back after you have removed it;
  • an account is in the database and hidden from the Users screen;
  • you find a plugin, a must-use plugin or a file that nobody can explain;
  • the site holds customer accounts, orders or payment details.

Our malware removal service is a one-time clean-up with hardening, a blacklist removal request and a written report, and if the infection comes back within 30 days we clean the site again.

Common questions

Can I just delete the unknown administrator?

Not as the only step. Whoever made the account still has whatever let them make it: a password, a vulnerable plugin or a file on the server. Record the account, delete it, reset every administrator's password, replace the secret keys and check for anything else that was added.

I already deleted it. What now?

Do the rest of the removal steps. The account's sessions are gone, but the access log still holds the requests from that day, so ask your host for it and search the hours around the time you first saw the account. Then run the database query again over the following days.

The unknown account is not an administrator. Does it matter?

It depends on the role. On a site with registration open, unknown subscribers are ordinary, and a subscriber can only manage their own profile. An unknown editor or author can publish, so treat it the same way as an unknown administrator. Any account with a role above the one your settings give to new users was given that role by someone.

Is the "New User Registration" email a sign of a hack?

Not by itself. WordPress sends it to the administration email address whenever a user registers or is added in the dashboard. Look up the account it names. A subscriber on a site that allows registration is normal. An administrator nobody added is not.

What can I do without SSH or WP-CLI?

Most of it. Run the database query in phpMyAdmin from your hosting control panel. Delete the account and revoke application passwords in the dashboard. Replace the secret keys by editing wp-config.php in your host's file manager. Ask your host for the access log, and for the list of files in wp-content/mu-plugins.

More on this subject

Malware removal, done for you

Malware removal is $99. Full clean-up, hardening, blacklist removal request and a written report. 30-day re-clean guarantee. It starts with a free diagnosis.

Get a free diagnosis