WordPress hacked: admin users added you didn't create

A new name in Users → All Users, role Administrator, created on a date you don’t recognise. Sometimes the email is a random string, sometimes it copies yours with one letter changed. If your WordPress site was hacked and admin users were added, that account is the symptom, not the break-in. Someone already had enough access to create it, and the account is there so they keep that access after you patch whatever let them in.

This guide covers what the account means, the cleanup order that actually closes the hole, and what a registration guard can and cannot do afterwards.

What an unexpected administrator means

An attacker who creates an administrator has already run code on your site or signed in as someone who could. There are four common ways that happens.

• A plugin or theme vulnerability. A privilege-escalation or arbitrary-code bug in an installed plugin lets an unauthenticated request call the same functions your dashboard does. This is the most common cause, and abandoned plugins are the usual source.
• Stolen or reused credentials. An admin password used on another site that leaked, guessed by a brute-force run against wp-login.php or xmlrpc.php, or taken from an infected computer’s browser.
• A leftover backdoor. A site cleaned once before still has a PHP file in uploads or a line in a theme file that recreates the account on demand. Deleting the user without finding the file means it comes back in a week.
• Open registration plus a role bug. “Anyone can register” left on, combined with a plugin or a custom form that sets the role from a request field, lets a visitor register straight into the administrator role.

What to do now, in order

Work top to bottom. Skipping a step is how the account returns.

1. Remove the accounts. Delete every user you didn’t create. When WordPress asks what to do with their content, attribute it to yourself rather than deleting, so you can see what they posted or changed. Note the usernames and emails first; they help when searching files and logs.
2. Force a password reset for everyone. Every administrator, editor and any account with an API key. Assume the attacker read the database, which holds every password hash. Change your database and FTP or SSH passwords at the host too.
3. Rotate the salts in wp-config.php. The eight AUTH_KEY to NONCE_SALT lines sign every login cookie. Replace them with fresh values from the WordPress secret-key service. Every session, including the attacker’s, is signed out at once.
4. Update everything. WordPress core, every plugin, every theme, including inactive ones, which still run code if their files are requested directly. Delete what you don’t use rather than leaving it deactivated.
5. Scan the files. Compare core, plugin and theme files to fresh copies. wp core verify-checksums and wp plugin verify-checksums --all with WP-CLI report changed files for anything hosted on wordpress.org. A security scanner plugin or your host’s malware scan covers the rest.
6. Look for a second administrator in the database. The users list can be filtered by a hook, so check the tables directly. In wp_users joined with wp_usermeta, the row whose meta_key is wp_capabilities names the role. Anything containing administrator that you didn’t create is the next account to remove.
7. Search uploads for PHP. find wp-content/uploads -name "*.php" should return nothing. A PHP file there is a backdoor. Delete it and check the file dates for others changed at the same time.
8. Check scheduled events and mu-plugins. wp cron event list shows scheduled tasks; an unfamiliar hook name that runs hourly is a common way to recreate a user. wp-content/mu-plugins loads on every request with no activation step and no entry on the Plugins screen, so look at every file in it.

Once the site is clean, check the plugin list against a vulnerability database and remove whatever let them in. If you can’t identify the entry point, restore from a backup taken before the account appeared, then repeat steps 2 to 4 on the restored copy.

Reduce the attack surface afterwards

The entry point was almost always installed code. The guide on blocking plugin installs covers why every plugin you add is attack surface, and DISALLOW_FILE_MODS versus DISALLOW_FILE_EDIT covers switching off the file editors an attacker uses to plant a backdoor from the dashboard. Turn “Anyone can register” off if the site doesn’t need it, and read how to stop spam user registrations in WordPress for why that checkbox alone closes only one door. If a stolen or reused password was the way in, add a second step to the administrator login, so a password alone is no longer enough: WordPress two-factor authentication by email covers the simplest kind.

What Adminkeep does, and what it does not do

Adminkeep is a free plugin made of small features with one switch each. One of them blocks user registration; the setting is called Registration Lockdown in the plugin. It works in three layers.

• The registration form is closed. “Anyone can register” is forced off by filter, so it stays off even if something flips the option row in the database, and wp-login.php?action=register stops working. Unauthenticated user creation through the REST API is refused too.
• The administrator guard, on by default. Creation of a new administrator is refused whether it comes from Users → Add New, a plugin’s code, or a script calling wp_insert_user(), because the guard hooks the one filter every path passes through. Promoting an existing user to administrator is refused too. Administrator is removed from the role dropdowns, so nothing errors; the option is simply not offered. WooCommerce checkout and membership signups are untouched, because they create customers and subscribers, not administrators.
• Blocking plugin-created accounts, off by default. For sites that want no new accounts at all. Leave it off if you run a store or a membership plugin.

Blocked administrator attempts are recorded with the time and the requested username, and only the newest twenty are kept, so a script hammering the site can’t turn into a database write on every try. If the guard was on when the attacker tried, the log shows you the attempt and the name they wanted.

What it does not do matters just as much. It does not clean malware, and it does not close the hole that let the attacker in. A backdoor that runs SQL against the database can insert a row into wp_users and wp_usermeta directly, and no WordPress filter sees that. The guard raises the cost of the attacker’s first move and gives you a record of it. The cleanup list above is still the job.

Questions people ask

My WordPress site was hacked and admin users were added. Is deleting them enough?

No. The account is the attacker's way back in, not the way they got in. Delete it, then reset every password, rotate the salts, update everything and scan the files, or the account reappears.

How did an attacker add an administrator to my WordPress site?

Usually through a vulnerable plugin or theme, stolen or reused credentials, a backdoor left from an earlier compromise, or open registration combined with a plugin bug that sets the role.

Does Adminkeep stop hackers from adding admin users?

Its registration guard refuses creation of, or promotion to, administrator through the dashboard and plugin code, and logs the attempt. It does not clean malware, close the hole, or stop a backdoor that writes to the database directly.

Where do I look for a hidden administrator in WordPress?

In the wp_users table joined with wp_usermeta, where the capabilities row names the role. Also check the uploads folder for PHP files, the mu-plugins folder, and the scheduled events list.