An admin account I never created has appeared
It is the opening move in almost every recent WordPress intrusion: create an administrator account, sometimes hidden from the user list, so access survives long after the original flaw is patched.
Why the admin account comes first
In nearly every WordPress intrusion documented in recent months, the administrator account isn’t the goal — it’s what makes everything else possible. A flaw gives narrow access, often one request wide, in one specific context, and it eventually gets patched. An admin account gives broad, lasting access that the site treats as entirely legitimate. Once it exists, the attacker no longer needs the original flaw: patch the offending plugin and they still walk in through the front door.
Recent cases all share this pattern. For CVE-2026-3300 in Everest Forms Pro, patched on 18 March 2026 and actively exploited from 13 April 2026, the published indicator of compromise is unusually simple: an administrator account named diksimarina. For CVE-2026-8181, affecting Burst Statistics 3.4.0 and 3.4.1 across roughly 200,000 active installations, an unauthenticated attacker could fully impersonate an administrator for the duration of a REST API request and use that position to create their own admin accounts. Over 7,400 attacks were blocked in twenty-four hours before version 3.4.2 shipped on 12 May 2026.
Creation isn’t always the first move. In the ShapedPlugin distribution chain compromise published on 22 June 2026, the tampered code began by exfiltrating the contents of wp-config.php and the site’s administrator accounts. Nothing was created there: it was read, along with everything needed to come back later without adding a new row to the list.
What you see, or fail to see
- An unfamiliar row in the admin user list, carrying the Administrator role.
- The user counter shows a higher total than the number of rows actually displayed.
- An administrator whose email address belongs to nobody you know, often on a generic domain.
- A registration date matching nobody joining the team.
- An existing account whose role has been raised to administrator without anyone asking.
- A WordPress notification about an account creation or an email change nobody triggered.
- An account you deleted reappearing hours or days later.
An account can exist without showing in the list
The nastier case isn’t the unfamiliar row you can see: it’s seeing nothing while an account exists. WordPress builds the user list through its own filters, and a malicious plugin can hook those filters to drop a row from the output. The phishing campaign documented by Patchstack in April 2025 did exactly that: the plugin the victim downloaded, dressed up as a WooCommerce security patch, created an administrator account with a random eight-character name, then hid itself from the plugin list and hid the account it had just created.
Two checks get around that without installing anything. First: compare the total user count shown above the list with the number of rows actually displayed, then repeat the comparison role by role. A gap of one is enough to justify going further. Second: read the wp_users table directly in the database, through phpMyAdmin or your host’s tool, allowing for the table prefix your installation actually uses. The database passes through no PHP filter; it is the only source that tells the truth. Look at wp_usermeta too, where roles are stored — that is where a quiet account gets its administrator rights.
The same caveat applies on the command line. WP-CLI loads WordPress, therefore the plugins, therefore the filters: a plugin hiding an account in the dashboard can hide it from WP-CLI output as well. The command below is still the fastest way to get a clean list with registration dates, but if it shows nothing while the counter says there is one user more, believe the counter and go to the database.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user list --role=administrator --format=countWhat to record before touching the account
-
Record the registration date and time
The <code>user_registered</code> field gives the exact moment the account was created. Everything else pivots on it: without it, I don’t know which window to search.
-
Record the login, email address and role
I keep these off the site, in a file or a note. Once the account is deleted they are gone for good, and they are what lets the same actor be recognised elsewhere.
-
Pull the logs before they rotate
Host access logs are often kept for a few days only. I download the registration day plus the two days before it, along with the PHP error logs for the same period.
-
Look for what else moved at that moment
Files created or modified around that timestamp, unusual scheduled tasks, plugins installed or deactivated, content published. The entry point is usually there, not in the account itself.
-
Check the other accounts, not just the new one
An old account promoted to administrator, an email address changed, an application password added: the visible row is sometimes bait, meant to be found and deleted while a second way in stays put.
-
Only then: delete, reset, log everyone out
Delete the account, reset every administrator password, invalidate open sessions, regenerate the security keys in <code>wp-config.php</code>.
Related reading
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.