An unknown WordPress admin user should be investigated as a possible compromise, even if it does not appear in the dashboard's Users screen. Check the user list with WP-CLI and the WordPress database, record what you find, remove unauthorized access safely, then look for the malware or stolen credentials that created it.
Attackers create accounts because a username and password can survive a file cleanup. Some malware hides its account from the normal Users screen, so a quick dashboard review is helpful but not conclusive. The goal is to build a complete list of access, not to guess based on a username that looks suspicious.
Start with the dashboard, but do not stop there
Open Users in the WordPress dashboard and identify every account, its email address, role, and owner. Ask your team, agency, and former contractors about accounts you cannot place. A name like admin, wpadmin, or a variation of a real employee name may be suspicious, but a normal-looking name can be unauthorized too.
Check every role, not only Administrator. Subscriber, Customer, Contributor, Author, Editor, Shop Manager, and custom roles may all be legitimate depending on the site. What matters is whether the account belongs to a real person or service, needs current access, and has the permissions it should have.
Record the username, user ID, email address, role, registration date, and any relevant posts or orders before making changes. This preserves a useful incident record and helps you reassign content safely. Do not announce the suspected username publicly or use it as a password clue.
Use WP-CLI to get a list malware may not hide
WP-CLI reads WordPress data directly and can reveal users that a malicious dashboard filter tries to omit. From the WordPress root, run wp user list --fields=ID,user_login,user_email,roles,user_registered --format=table. This produces a reviewable list with the account's role and registration date.
For a smaller list of visible administrators, run wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --format=table. Review both outputs. The administrator-only command is useful, but it will not catch a user whose role metadata is manipulated or a lower-role account given extra privileges.
If your server has several WordPress sites, make sure you run the command in the correct site's document root. If the command produces an error, do not assume the problem is gone. It may need to run under the correct server user or have access to the site's wp-config.php. Your host or developer can help with the environment without sharing credentials in chat or email.
Compare the registration dates with known events: a new contractor, a site launch, a plugin migration, or the first report of suspicious behavior. A date alone does not prove compromise, but it can focus your file, log, and backup review.
Check the database when the dashboard and CLI do not agree
WordPress stores user records in the wp_users table and role capabilities in wp_usermeta. The wp_ prefix is common but not universal, so first confirm the table prefix in wp-config.php. For a site using the default prefix, start by reviewing wp_users for unfamiliar ID, user_login, user_email, user_registered, and display_name values.
Then inspect wp_usermeta entries whose meta_key ends in _capabilities. The value describes role capabilities for each user. A database review can show an account that a compromised dashboard hides, and it can reveal capability data that does not fit the role you see in the UI.
Use a database client with read-only access where possible, and take a backup before editing anything. A user record and its metadata are related, so deleting a single row without understanding the associated metadata can leave a confusing partial state. If you are not comfortable querying the production database, export a protected copy or ask a qualified developer to review it.
Look beyond accounts labeled Administrator
An account does not need the Administrator label to be risky. WordPress permissions are capabilities, and custom roles or altered metadata can grant a user sensitive actions beyond what its displayed role suggests. In particular, investigate an Editor or other non-admin account that has capabilities such as manage_options or install_plugins.
manage_options can allow changes to important site settings. install_plugins can allow new plugin code to be placed on the site. Those capabilities may be intentional in a custom setup, but they deserve an owner, a documented reason, and periodic review.
This is not only a theoretical concern. The October 2026 UpdraftCentral incident is a reminder to check effective privileges, not just the role name shown in the Users screen. Review custom role plugins and any code that adds capabilities, then compare the result with what each person actually needs.
Also check application passwords, API integrations, and hosting users. A clean WordPress user list does not rule out access through a compromised hosting panel, SFTP key, database credential, or plugin token. The signs of a hacked WordPress site article can help you broaden the review without losing focus.
Remove unauthorized users without losing needed content
Once you have confirmed an account is unauthorized, preserve the account details and then remove its WordPress access promptly. In the dashboard, delete the user and choose whether to attribute any posts to another known user or delete them. Do not automatically reassign content until you have reviewed it, because attacker-created posts, pages, or orders may be evidence or unwanted content.
With WP-CLI, you can remove a confirmed account using wp user delete USER_ID. Add --reassign=KNOWN_USER_ID only when you have chosen the correct owner for the account's content. Use numeric IDs you recorded rather than a similar-looking username. Check the user list again afterward to confirm the intended account is gone.
If you find several unknown users, consider the site compromised rather than treating each as an isolated cleanup. Look for WordPress backdoors, unfamiliar plugins, modified theme files, and suspicious database options. An attacker who could add an account may have left another way in.
Change credentials and remove the way back in
Deleting an account does not remove stolen passwords or server-level access. Reset passwords for all WordPress administrators, then rotate hosting control-panel, SFTP or SSH, database, and service credentials that may be exposed. Use unique passwords from a clean device, and enable multi-factor authentication wherever your WordPress host and related providers support it.
Update WordPress, plugins, and themes after removing anything unused. Identify the original entry path, whether it was an outdated plugin, reused password, abandoned account, or another issue. Review file changes and logs around the user's registration date when logs are available. The WordPress keeps getting hacked guide explains why fixing only the visible symptom leads to repeat incidents.
Prevent hidden accounts from becoming a surprise
Make user review part of routine maintenance. Keep a short access register that names each administrator, agency account, integration, and expected role. Remove accounts immediately when a contractor leaves or a responsibility changes. Use the least privilege that works, especially for people who edit content but do not manage plugins or site settings.
Periodically compare the dashboard list with wp user list --fields=ID,user_login,user_email,roles,user_registered --format=table. Review custom roles and capabilities after plugin changes. Keep backups separate from the live hosting account and make sure you can identify a clean restore point. These basic controls complement the steps in the WordPress hardening checklist.
When to get help
Get help if a hidden user returns, role capabilities are unclear, or you find evidence that someone used the account to change files or payment settings. West Oakbridge can investigate through WordPress malware removal or a focused security audit.