Rogue and Hidden Administrators

A planted WordPress administrator can be filtered out of your own Users screen. Reading the user tables twice, and reporting when the two answers disagree.
What this check and mySites.guru tool looks at on your site
This check reads your administrator accounts twice, from two different places, and reports both what it found and whether the two answers agree.
Straight from the database
The account list, and the roles attached to it, read with a plain query against wp_users and wp_usermeta. This is the answer to trust and the list you see.
Through WordPress itself
The same question asked the way your own Users screen asks it.
An account is reported as rogue when its username and email follow a pattern a known attack campaign generates: a role word followed by a run of hexadecimal characters, along with the rest of that campaign’s fingerprint. The rule does not fire on an ordinary account with digits in the name, so your own backup_20260913 is safe.
An administrator with no valid registration date is reported separately as worth a look. That means the row was written straight into the database rather than created through WordPress, which a migration or a command-line import does too. mySites.guru never offers to delete one of those, and they never mark a site as hacked.
The disagreement between the two readings is itself a finding
WordPress lets any plugin rewrite the answer to “who are the users on this site”, and on a site that has been broken into the attacker’s code is loaded and running inside the same request. So when the database holds more administrators than WordPress admits to, something is filtering the list, which is how a planted account stays invisible on the screen you would check. We hold the database answer, so we can see what your own Users screen may not.
Only that one direction counts as hidden. WordPress reporting more administrators than the database holds is a real disagreement too, but it is not a concealed account, because a plugin granting admin rights without a database role produces the same mismatch. That case is reported as information.
What the comparison cannot see
An attacker who leaves the account list alone and instead changes how the Users screen draws itself. Both numbers come out the same and the account is still missing from your screen.
That is why the username check matters independently of the disagreement. On the site this family was pulled apart on, the planted administrator was found by its name and not by any count mismatch: the filter it installed rewrites the links above the Users table and does not touch the user query at all. Neither check covers the other, so read both.
What a planted administrator tells you about the break-in
Someone already had enough access to write to your database before that account existed, and they did not stop there. The account exists so that the attacker keeps access after you close the hole they came in through: with a valid login they need neither the original vulnerability nor a webshell, so one cleanup becomes the next one.
On the compromise this check was built from, four such accounts could be accounted for across five months. Two had already been deleted by the time anyone looked, one was in the backup, and one was created after the backup was taken.
Every administrator accounted for
Every account holding administrator rights is one you can name, with a real email address your team controls and a plausible registration history. The number mySites.guru reads from your database matches the number WordPress reports, and it matches what you see on your own Users screen.
How to fix it
- Delete the accounts, then keep going. Deleting them closes that particular door and nothing else. Whatever created them can create more.
- Change the passwords on every remaining administrator, and force everyone to sign in again by rotating the authentication salts in
wp-config.php. - Run a full audit and work through every file it flags, then check your scheduled events and your must-use plugins and drop-ins. This family plants all three.
- Compare our list against your own Users screen. If mySites.guru can see an account you cannot, that difference tells you something is still running on the site.
- Check the rest of your portfolio. One search finds that user on every site you manage, which is the fastest way to find out how far a campaign reached.
What mySites.guru does about it
On every snapshot, twice a day, mySites.guru reads your user tables directly and compares that answer with WordPress’s own. A rogue account marks the site as hacked and appears in the red card.
Accounts can be deleted from the tool. Their content is reassigned to an administrator who stays, and the delete will not run if removing them would leave the site with no one holding the keys. It also skips the account you are signed in as, re-checks each account against a fresh read before removing it, and caps a batch so a single mistake cannot empty your user table.
On a multisite network administrator rights are held per site and mySites.guru reads the one you registered. The delete will not run on a network at all: removing a user there behaves differently and belongs to a network administrator who can see the whole picture.
Rogue and Hidden Administrators
mySites.guru checks every connected site for this automatically and flags it the moment it appears. These run twice a day on every connected site.
Further Reading
- Five New Checks for WordPress Hacks a File Scan Cannot See - the compromise this check was built from, including the filter that kept a planted administrator off the Users screen
- Finding Rogue Admin Accounts Across Every Joomla Site You Manage - the Joomla equivalent, which resolves Super User by ACL permission rather than by group name
