Skip to content

Web Development

Unknown Admin Accounts and File Manager Plugins: Hidden WordPress Risks to Check After PHP2Shell

How to spot an unknown admin account in WordPress, what to do before you delete it, and why file manager plugins and the file editor put your site at risk.

WordPress Users screen filtered to administrators, with an unknown admin account outlined in amber on a test site with sample accounts.
The Users screen on our local WordPress 7.1.3 test site with sample accounts, filtered to Administrator. The highlighted sample account has a random-looking username, a blank Name column, an unfamiliar email domain and no posts.

After PHP2Shell was disclosed in October 2026, we helped website owners check and coordinate patching on their WordPress sites; our earlier guide covers the flaws themselves. A patch fixes the vulnerability, but it doesn't tell you who already has a key. Our follow-up review found file editor and file manager plugins, and user accounts nobody could readily match to a known owner. Any unrecognized account deserves a check, and an unknown admin account is the most dangerous kind. This guide shows you how to spot one in WordPress, what to do before you delete it, and how to remove the file-editing tools that make a stolen login so damaging.

What We Found When We Looked Past the Patch

Patching closes the door. A security review checks whether anyone already walked through it, and what would make the next break-in worse. After the PHP2Shell work, we reviewed several live and staging WordPress environments for website owners, looking at visible user roles, security-related activity and the available web-server and PHP error logs.

Where supported, we created recovery points before or during the review and kept a dated record of the environment state. Observed findings stayed separate from items that still needed checking.

Two risks stood out, and neither depends on PHP2Shell. The table sums them up without client details or counts.

What our post-patch WordPress review found, anonymized.
FindingWhat we sawWhy it matters
File editor and file manager pluginsDashboard tools that let a logged-in user edit files on the server.Anyone who gets that login, or exploits a flaw in the plugin, can add or change PHP code on the server.
Suspicious user accountsAccounts nobody could readily match to a known owner, recorded for ownership checks rather than judged on sight.An account nobody can vouch for may be a forgotten login or a sign of unauthorized access. Until someone verifies it, you can't tell which.
Signs of compromiseNo confirmed compromise in the sampled evidence. This was not a full forensic clearance.Finding no confirmed compromise in limited evidence lowers concern; it is not proof that nobody got in.

Why One Admin Account Is All an Attacker Needs

The administrator (admin) role is the highest level of access on a standard WordPress site: an admin can add users, install plugins, switch themes and change any setting. That is why an unknown admin account matters more than any other stranger on your site. On most sites, an admin login is not just access to content; it is a route to running code on your server.

The chain from login to takeover is short, and every step uses ordinary WordPress features.

  1. Admin access: a stolen password, a forgotten account, or a new one someone created.
  2. A way to write files: a plugin upload, the Theme or Plugin File Editor, or a file manager plugin.
  3. PHP code on the server: the attacker's own code now sits among your site's files.
  4. A backdoor: hidden code or an extra account that keeps the attacker in after you change passwords.
  5. Full takeover: the attacker can change any file or setting, and deleting the original account no longer locks them out.

What Attackers Did After the wp2shell Attacks

This chain is not theoretical. After the July 2026 "wp2shell" attacks on WordPress core, Wiz reported attackers uploading plugins containing webshells through the normal plugin installer, and InMotion Hosting's recovery write-up describes attackers creating new administrator accounts. A webshell is a small hidden script that lets an attacker run commands on your server from a browser.

InMotion Hosting also describes how attackers kept their foothold. They added a must-use plugin (mu-plugin: a plugin WordPress loads automatically and that can't be switched off from the Plugins screen) that restored deleted files. They also hid PHP files in the uploads folder disguised as core class files, and stored encoded payloads in the wp_options database table.

Don't confuse the two: wp2shell was a pair of WordPress core flaws (CVE-2026-63030 and CVE-2026-60137), while PHP2Shell is a pair of flaws in PHP itself. wp2shell shows what attackers do once they reach admin level, but it doesn't explain anything in our review.

How to Spot Unknown or Suspicious Admin Accounts in WordPress

Start with the dashboard, confirm with a second source, then rule out innocent explanations.

Check the Users Screen

Go to Users → All Users and click the Administrator filter. The number in parentheses is your admin count, and you should be able to name the person behind each one.

Then check each row for these warning signs.

  • An administrator nobody on your team recognizes.
  • A generic or random-looking username, such as a word plus a string of letters and numbers.
  • An email address on a domain unrelated to your business, or a disposable inbox.
  • Admin rights with no posts or other legitimate activity.
  • A registration date clustered around a known incident (the Users screen doesn't show it, so use the next check).

Double-Check With WP-CLI or the Database

Don't rely on the Users screen alone. Some malware hides rogue administrator accounts from it, so your dashboard can look normal while an extra admin still exists.

For developers: WP-CLI is the official command-line tool for managing WordPress from a server terminal. The command below lists every administrator with their ID, username, email and registration date, and it changes nothing.

Compare the output with the Users screen and question any registration date you can't explain. If an account appears here but not in the dashboard, or you want the final word, have your host or developer check the database directly.

For developers

Read-onlyLists every administrator with ID, username, email and registration date.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Rule Out Innocent Explanations

Innocent explanations are common: a former employee, a contractor, the agency that built the site, or a plugin or host support account that nobody removed. Treat the account as suspicious until someone verifies it, but don't call it malicious without evidence.

If a legitimate owner turns up, check that they still need full control: a former contractor's account should go, and a content writer can move to the Editor role.

  • Ask your team, past agencies and your host whether the account is theirs.
  • Match the registration date to onboarding records, contracts or support tickets.
  • Contact the person through details you already have, not the account's email.
  • Check its posts, plugin installs, settings changes and logins in your activity log.
WP-CLI administrator list showing user IDs, usernames, emails and registration dates on our local WordPress test site with sample accounts.
Read-only WP-CLI output on our local WordPress 7.1.3 test site with sample accounts. The registration dates show the sample account wpadmin_x7k2 was created on September 28, 2026, long after the other three.

Found One? What to Do, Step by Step

Work through these steps in order. Deleting first feels safest, but it destroys the evidence you need.

If a step feels beyond you, stop after step 3 and get help, since locking the account cuts off its current logins while you get help. The developer commands after the list match steps 3, 5, 6 and 7.

  1. Don't delete it yet. Deleting erases clues about when it appeared and what it did.
  2. Document it. Screenshot the Users screen and note the user ID, username, email and registration date.
  3. Lock it. Reset its password and end all of its sessions, so its current logins stop working.
  4. Check what it did: posts, plugin installs, file changes, and activity and server logs from around its registration date.
  5. Remove it and reassign its content to a known account, so nothing is lost.
  6. Rotate passwords and salts. Change every admin password, then replace the salts (security keys: random values in wp-config.php that protect login cookies), which logs everyone out.
  7. Verify core and plugin integrity. A file integrity check flags core or WordPress.org plugin files that differ from the official release; it can't vouch for themes or for premium and custom plugins, so have those reviewed separately. Also check the uploads folder for PHP files and the mu-plugins folder for anything unfamiliar.
  8. Decide whether this is an incident. If the account installed plugins, changed files or created users, follow the recovery steps further down.

For developers

Makes a changeLogs the user out of every browser and device.
wp user session destroy <user> --all
Makes a changeDeletes the user and hands their content to another account.
wp user delete <ID> --reassign=<ID>
Makes a changeReplaces the salts (security keys) and logs every user out.
wp config shuffle-salts
Read-onlyCompares WordPress core files with the official checksums.
wp core verify-checksums
Read-onlyChecks every plugin from WordPress.org against its official checksums.
wp plugin verify-checksums --all
Read-onlyFinds PHP files in the uploads folder, where they rarely belong.
find wp-content/uploads -name "*.php"
Read-onlyLists the must-use plugins folder so you can spot files nobody added.
ls wp-content/mu-plugins
WP-CLI output showing WordPress core and plugin checksum verification passing on our local WordPress test site.
Read-only integrity checks on our local WordPress 7.1.3 test site: core files and all three WordPress.org plugins match their official checksums.

File Manager Plugins and the Built-In File Editor: Convenient, and Dangerous

Both tools exist to save time. Both also mean that whoever holds an admin login can change the code your site runs, straight from a browser.

What They Do, and Why Attackers Love Them

WordPress includes a Theme File Editor and a Plugin File Editor, under Appearance, Plugins or Tools depending on your theme. They let any administrator edit PHP files from the browser.

File manager plugins go further, adding full file-system access inside wp-admin: upload, edit or delete any file.

For an attacker, that is the ideal shortcut. With an admin login, or a flaw in the plugin itself, it becomes instant code execution on your server.

A Real Example: CVE-2020-25213 in the File Manager Plugin

The File Manager plugin (wp-file-manager) shows how bad a plugin flaw can get. Versions before 6.9 let attackers who had never logged in upload and run PHP files through a bundled elFinder connector file.

NVD rates it CVSS 9.8 out of 10 (critical). Rapid7 and NVD say it was exploited in the wild in August and September 2020, SonicWall reported active exploitation that year, and it is listed in CISA's Known Exploited Vulnerabilities catalog.

The lesson goes beyond one plugin: every tool that can write files to your server is another way in.

How to Remove the Risk

First, delete file manager plugins. For file changes, use SFTP (an encrypted file transfer connection) or your host's file manager, which sit behind your hosting login instead of your WordPress login.

Next, turn off the built-in editors with one line in wp-config.php, the main WordPress configuration file. DISALLOW_FILE_EDIT removes both editors, and normal updates keep working.

That doesn't close every door. Admins can still upload a plugin ZIP containing PHP unless DISALLOW_FILE_MODS is set, so who holds an admin account matters as much as which plugins you run.

DISALLOW_FILE_MODS blocks installing, updating and deleting plugins and themes from the dashboard, dashboard updates included. Only use it when updates happen another way: WP-CLI, your host or a deployment pipeline.

For developers

Read-onlyLists plugins with status, version and available updates.
wp plugin list --fields=name,status,version,update
Makes a changeAdd this line to wp-config.php, above the "That's all, stop editing!" comment.
define( 'DISALLOW_FILE_EDIT', true );
Makes a changeAdds the same setting with WP-CLI.
wp config set DISALLOW_FILE_EDIT true --raw
Makes a changeAlso blocks plugin and theme installs and updates from the dashboard.
define( 'DISALLOW_FILE_MODS', true );
WordPress Tools menu on our local test site, before and after DISALLOW_FILE_EDIT is set, with the Theme File Editor and Plugin File Editor removed.
Before and after on our local WordPress 7.1.3 test site: the Theme File Editor and Plugin File Editor disappear from the Tools menu once DISALLOW_FILE_EDIT is set with WP-CLI.

A 30-Minute WordPress Security Self-Audit

Run this checklist monthly, and whenever someone joins or leaves your team. Most items need no technical skills; pass the rest to your developer or host, and keep a dated note of what you checked.

0 of 12 done

When It's an Incident, Not Housekeeping

Most of this guide is housekeeping. Some findings, though, mean someone may already be inside, and then the order of your next steps matters.

Get professional help now if you see any of these signs.

  • An admin account that appears in WP-CLI or the database but not on the Users screen.
  • PHP files in the uploads folder, or must-use plugins nobody on your team added.
  • Core or plugin files that fail their checksum check.
  • An unrecognized account that installed plugins, edited files or created other users.
  • Accounts or files that come back after you delete them.
  • A warning from your host about malware or unusual activity on your account.

The Recovery Basics, in Order

If you see one of these signs, slow down. Cleaning first is how evidence gets lost and attackers keep a way back in.

  1. Preserve evidence: save the logs, plus a copy of the files and database, before you change anything.
  2. Remove access: lock or delete the accounts and files involved, once they are documented.
  3. Rotate all credentials: WordPress passwords, the database password, the hosting panel, SFTP or SSH logins, and API keys.
  4. Shuffle the salts so every existing login session ends.
  5. Restore from a known-clean backup if a compromise is confirmed, instead of trying to delete the bad parts by hand.
  6. Monitor closely afterwards for returning accounts, new files and unusual logins.

Verified references

Sources & Methodology

Facts in this guide were checked against the sources below on October 23, 2026. The screenshots come from our local WordPress 7.1.3 test site with sample accounts, not from any client website. This article is general guidance, not a finding about any particular website.

  1. Exploitation in the Wild of wp2shellWiz Research: Attacker behavior after the July 2026 WordPress core attacks, including webshells uploaded as plugins through the plugin installer.
  2. Inside wp2shell: WordPress compromise and recoveryInMotion Hosting: New administrator accounts and persistence methods seen after wp2shell, including a must-use plugin, PHP files in uploads and encoded payloads in wp_options.
  3. CVE-2020-25213: WordPress File Manager pluginRapid7: Affected versions and exploitation in the wild in August and September 2020.
  4. Nessus plugin 140211: WordPress File Manager plugin (CVE-2020-25213)Tenable: Vulnerability details for File Manager versions before 6.9.
  5. CVE-2020-25213 detailNIST National Vulnerability Database: Official CVE record: CVSS 9.8, exploited in August and September 2020.
  6. Hardening WordPressWordPress Developer Resources: Official security hardening guidance.
  7. Editing wp-config.phpWordPress Developer Resources: DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS.
  8. Roles and CapabilitiesWordPress Documentation: What the administrator, editor and other roles can do.
  9. wp user listWordPress Developer Resources: Official WP-CLI command documentation.
  10. wp user session destroyWordPress Developer Resources: Official WP-CLI command documentation.
  11. wp user deleteWordPress Developer Resources: Official WP-CLI command documentation.
  12. wp config setWordPress Developer Resources: Official WP-CLI command documentation.
  13. wp config shuffle-saltsWordPress Developer Resources: Official WP-CLI command documentation.
  14. wp core verify-checksumsWordPress Developer Resources: Official WP-CLI command documentation.
  15. wp plugin verify-checksumsWordPress Developer Resources: Official WP-CLI command documentation. Covers plugins from WordPress.org only.

Clear answers before you plan

Frequently Asked Questions

Does an unknown admin account mean my WordPress site was hacked?

Not necessarily. Many unknown admin accounts belong to former staff, contractors, agencies or support teams and were simply never removed. Still, treat the account as suspicious until someone verifies it, because an administrator can install plugins and change code. Lock it, document it and check what it did before you decide whether it is a leftover login or a sign of a break-in.

Should I delete a suspicious admin account straight away?

No. Lock it first by resetting its password and ending its sessions, then record its user ID, username, email, registration date and activity. Deleting it straight away destroys clues you may need later. Once you know what it did, delete it, reassign its content to a known account, and rotate passwords and salts.

Can hackers hide admin accounts in WordPress?

Yes. Some malware hides rogue administrator accounts from the Users screen, so your dashboard can look normal while an extra admin still exists. Check with WP-CLI using wp user list --role=administrator, or ask your host or developer to look at the users in the database directly. If the lists don't match, treat it as a possible incident.

Is the WordPress theme file editor safe to use?

It works, but it is a risky habit on a live site. The Theme File Editor lets any administrator change PHP code from the browser, so a stolen admin login becomes a way to run code on your server. Make changes through SFTP or your normal development workflow instead, then turn the editor off with DISALLOW_FILE_EDIT.

Are file manager plugins safe?

They add a risk most sites don't need. A file manager plugin gives anyone who can use it full control of your files from wp-admin, and a flaw in the plugin can hand that control to attackers who never log in, as CVE-2020-25213 showed in 2020. Use SFTP or your host's file manager instead, and delete the plugin.

What does DISALLOW_FILE_EDIT do?

It is a wp-config.php setting that removes the Theme File Editor and Plugin File Editor from the WordPress dashboard. Add define( 'DISALLOW_FILE_EDIT', true ); to the file, or run wp config set DISALLOW_FILE_EDIT true --raw. It doesn't block plugin uploads or updates. DISALLOW_FILE_MODS goes further, but it also stops dashboard updates.

If I've patched PHP2Shell, is my site clean?

Not necessarily. Patching closes the vulnerability, but it doesn't remove access someone may have gained before the patch or through another route. Our guide, Critical PHP Security Vulnerability in 2026: What WordPress Website Owners Need to Know, covers the patch itself. After patching, check your admin accounts, plugins and files with the steps in this article.

How often should I audit WordPress users?

Check your administrator list at least once a month, and every time someone joins or leaves your team or an agency finishes work on the site. Run a fuller check, with WP-CLI and a file integrity check, after any security scare or major vulnerability disclosure. The 30-minute self-audit checklist in this guide covers what to look at.

A practical next step

Need a Second Pair of Eyes?

If something on your Users or Plugins screen doesn't add up, you don't have to work it out alone. We can review accounts, plugins and file access with you, keep the evidence intact, and give you a clear list of what needs action.

Contact Conduit Code LabsSee website maintenance and support

Continue reading

View all Web Development