You log in to WordPress to update a page, glance at the Users screen, and there it is: an administrator called something like “wpsupport” or “admin2”, with an email address you have never seen. Nobody in the office remembers adding it. The site looks normal, orders are coming in, and you are left wondering whether this is a leftover from an old developer or a sign that someone else has the keys.
Both are possible. This post is about telling them apart, and about what to check before you press Delete, because deleting the account on its own rarely solves anything if it was planted.
Why a stranger would want an administrator account
An administrator in WordPress can install plugins, edit theme files from the dashboard (unless that has been switched off), and create more users. For an attacker, that is the whole site. An admin account is a comfortable way back in: it survives password changes on your own account, it works from any browser, and it does not need the original weakness to stay open.
That is why a planted admin is usually not the first thing an attacker did. It is something they set up after getting in by another route, such as a vulnerable plugin, a stolen password, or a file upload form that accepted more than it should have. The account is the souvenir. The real question is how they got far enough to create it.
If you want a refresher on what each role can and cannot do, our guide to WordPress user roles and least privilege covers that. Here we only care about the one role that matters in this situation.
Innocent explanations worth ruling out first
Before assuming the worst, spend ten minutes on the boring possibilities. Plenty of unexplained admins turn out to be legitimate.
- A past developer or agency. Whoever built or last maintained the site may have created their own login and never removed it. Check old emails and invoices for the name or domain in the account’s email address.
- Your hosting company. Some hosts and managed WordPress platforms add a support or staging account so their team can help when you open a ticket. The email domain usually gives this away.
- A service you connected. Some backup, migration or management tools create a user when you connect them. If you signed up for one and later forgot, its account may still be there.
- A colleague. Someone with admin access may have added a user for a freelancer and not told anyone.
If you can trace the account to a real person or company, ask them directly whether it is theirs and whether they still need it. If they do not, remove it properly. If nobody can explain it, carry on as though it is hostile until you have evidence otherwise.
Record the details before you change anything
The account itself is evidence. Once it is gone, so is the easiest clue to when the break-in happened. Before deleting or editing it, write down or screenshot:
- The username, display name and email address
- The user ID (hover over the name on the Users screen and look at the link, or open the profile and check the address bar)
- The registration date, if you can see it
- Any posts or pages attributed to it
WordPress stores a registration timestamp for every user, but the standard Users screen does not display it. If you or your host can run WP-CLI, wp user list --role=administrator --fields=ID,user_login,user_email,user_registered shows every admin with the date it was created. You can also see the same user_registered value in the users table through phpMyAdmin.
Treat that date as a hint rather than proof. If the account was inserted straight into the database, the attacker could have written any date they liked. Still, a registration time of 3:14 in the morning on a day nobody was working is worth matching against your server’s access logs.
Check whether there are admins you cannot see
Here is the part most owners miss. The Users screen is generated by WordPress code, and code can be changed. Some malware adds a small filter that hides its own account from the list, so the visible table looks clean while the hidden admin stays active.
There is a simple tell. Above the users table, WordPress shows a count next to each role, such as “Administrator (3)”. That number is calculated separately from the list itself. If the count says three and you can only see two rows when you filter by Administrator, something is hiding one of them.
The other way to see the truth is to look below WordPress, in the database. In the usermeta table, each user has a capabilities entry (its name starts with your table prefix, often wp_capabilities) that records their role. Any user whose entry contains administrator is an admin, whatever the dashboard shows. WP-CLI reads the database through WordPress too, so in a badly infected site it can be fooled as well; a direct database query is the more reliable check.
Look for the account changes that are harder to notice
A brand-new admin is the obvious version. Quieter changes do the same job, and they are worth checking at the same time.
An existing account with a new email address
Instead of creating a user, an attacker may change the email on a dormant admin, perhaps an old staff account. Now password reset links go to them. Open each administrator’s profile and confirm the email belongs to someone you know and still reaches them.
A lower account promoted
A subscriber or customer account created months ago, then quietly given the administrator role, does not look new in any list sorted by date. Check every admin, not only the recent ones.
The site’s admin email
Under Settings, then General, the “Administration Email Address” receives notices about new users, updates and some security events. If that has been changed, you would not hear about the next account either. When the address is changed from the dashboard, WordPress emails a confirmation link to the new address and only switches once it is clicked, so an attacker would need an inbox they control. A changed address with no confirmation step at all points to a direct database edit.
Application passwords and registration settings
Application passwords on a user profile, and the “Anyone can register” and default role settings, are covered in the user roles guide linked above. Look at them now with fresh suspicion rather than as housekeeping.
Find out whether the account will come back
A common pattern goes like this: the owner deletes the strange admin, feels relieved, and finds it back the next morning. That happens because the code that created it is still on the server, and it runs again on the next page load.
Places where that kind of code tends to sit include:
- The active theme’s
functions.php, often appended at the very bottom after hundreds of blank lines - The
wp-content/mu-pluginsfolder. Must-use plugins load automatically and appear only under a separate “Must-Use” filter on the Plugins screen, which many owners never open - A plugin with a believable name you did not install, or a real plugin folder with one extra file
- PHP files inside
wp-content/uploads, where nothing executable should normally live
Search the files for strings like wp_create_user, wp_insert_user or the exact username you found. Legitimate plugins use those functions too, so a match is a lead, not a verdict. What you are looking for is a match in a place that has no business creating users. Hidden scripts like this are the subject of our page on removing WordPress backdoors, which explains why they are the usual reason a cleanup fails.
What an unknown admin tells you about the rest of the site
If you have ruled out the innocent explanations, assume the attacker had administrator power for as long as that account existed. With that power they could have:
- Installed and later removed a plugin that dropped other files
- Edited theme files through the built-in editor
- Added scripts to posts, widgets or settings stored in the database
- Exported your user list, form entries or, on a store, customer details
None of that is certain, and in some cases the account was created and never used. But you cannot know which without looking. This is the point where the job stops being “remove one user” and becomes “check the whole site”. Our step-by-step guide to cleaning a hacked WordPress site walks through that wider process.
If a security or activity log plugin was already running before the account appeared, it may have recorded the user being created and what that account did next. Reading those records alongside the server logs is explained in our post on using activity logs after a hack. A log plugin installed today cannot see the past, but it will help you spot anything that happens from now on.
A sensible order of work
When the account is confirmed as unwanted, this order avoids the most common mistakes:
- Take a full backup first, files and database, even though the site is infected. It preserves evidence and gives you a way back if a cleanup step breaks something.
- Find and remove the code that creates or hides users before you delete the account, so it does not reappear.
- Delete the account and, when WordPress asks, assign any content to a real user rather than deleting it unseen.
- Reset every administrator’s password, including yours, from a device you trust.
- Change the security keys and salts in
wp-config.php. Doing that invalidates existing login cookies, which signs everyone out, including anyone who was logged in with a stolen session. - Change the passwords one level up: hosting panel, database user, FTP or SFTP, and the email account that receives password resets.
- Close the original entry point, usually by updating or removing the plugin or theme that let them in.
Skipping step 2 is the reason most owners see the account return. Skipping step 7 is the reason the whole problem returns a few weeks later.
If you are locked out instead
Sometimes the unknown admin is discovered the hard way: your own password no longer works, the reset email never arrives, or your account has been downgraded or deleted. That is a different starting point, because you need to regain control before you can investigate. Our service page on recovering WordPress admin access covers the routes back in through the hosting account and database.
When to stop and get help
You can handle a forgotten developer account yourself. A hostile one is different, especially if the site takes payments or stores customer data, if the account came back after you deleted it, or if the user count and the list do not match. At that point it is worth having someone look at the files and database together, rather than chasing one symptom at a time.
If you would like us to take a look, our hacked website repair and emergency help page explains how we work. Message us on WhatsApp and start with the word HACKED, tell us what you found on the Users screen, and we will tell you honestly what we see and when we can start. Nothing on the site is changed until a full backup exists.
Next in this series: Search Console Security Issues Report, Explained
