# 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.

- Source canonique : [https://allaux.fr/en/securite/compte-administrateur-que-je-n-ai-pas-cree](https://allaux.fr/en/securite/compte-administrateur-que-je-n-ai-pas-cree)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Do not delete the account yet: first read user_login, user_email and user_registered straight from the wp_users table, because the admin user list can be filtered by a plugin. Cross-check the real role in wp_usermeta. Then look inside wp-content/mu-plugins/ — while code runs there, the account will simply be recreated on the next page load.

## 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.

## terminal — at the site root

```
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user list --role=administrator --format=count
```

## What to record before touching the account

1. **Record the registration date and time** — The user_registered field gives the exact moment the account was created. Everything else pivots on it: without it, I don’t know which window to search.
2. **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.
3. **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.
4. **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.
5. **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.
6. **Only then: delete, reset, log everyone out** — Delete the account, reset every administrator password, invalidate open sessions, regenerate the security keys in wp-config.php.

## Delete the account without closing the entry point and it comes back

> The wp-content/mu-plugins/ folder holds must-use plugins: they load automatically on every page render, with no activation, and never appear in the dashboard plugin list. Sucuri found malicious files there in March 2025, including a webshell giving remote access to the server. While code like that is in place, deleting the admin account settles nothing — it can be recreated on the next page load, and you have destroyed the evidence in the meantime. The order never changes: record, understand the entry point, close the entry point, then clean up the accounts.

## Related reading

- **Checking whether your site is compromised** — The full method, beyond the user list alone. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **An unknown file on the server** — What to do with a file you never uploaded, and how to date its arrival. ([/securite/fichier-inconnu-sur-le-serveur](/securite/fichier-inconnu-sur-le-serveur))
- **Admin passwords and shared access** — What to reset once the entry point is closed, and in what order. ([/securite/mots-de-passe-administration-acces-partages](/securite/mots-de-passe-administration-acces-partages))

## FAQ

### Can I just delete the account and move on?

No. The account is a consequence, not a cause. While the flaw or backdoor that allowed it stays in place, it can be recreated. Delete it, but only after recording its registration date, its email address and the logs for that period.

### How was an admin account created if nobody stole my password?

In most recent cases no password is needed. With CVE-2026-8181 in Burst Statistics, an unauthenticated attacker could impersonate an administrator for the length of a REST API request and create accounts from there. Your password was never involved.

### The account is called diksimarina — does that mean anything?

Yes. It is the published indicator of compromise for exploitation of CVE-2026-3300 in Everest Forms Pro. Finding it points the investigation firmly at that flaw, but it doesn’t remove the need to check what was dropped on the server afterwards.

### I see no unknown account. Am I in the clear?

Not necessarily. An account can be hidden from the user list by code running on the site. Compare the user counter with the number of rows displayed, and read the users table directly in the database: that is the only view no filter touches.

### Should I change the other administrators’ passwords?

Yes, along with FTP, database and hosting account credentials. In the ShapedPlugin distribution chain compromise, the tampered code exfiltrated the contents of wp-config.php and the administrator accounts: anything read once stays usable until it is changed.