Backdoors Hiding in the mu-plugins Folder

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

You have been through the plugins screen a dozen times and everything on it is legitimate. You deactivated all of them and the malicious behaviour carried on anyway. If that describes your situation, there is a folder you probably have not looked in, and it is designed to hold code that runs no matter what you switch off.

What must-use plugins are

WordPress supports a second plugin directory at wp-content/mu-plugins. Anything placed there is a must-use plugin: it loads automatically on every request, before ordinary plugins, and it cannot be deactivated from the dashboard. There is no activation step and no deactivate link, because the whole concept is code that management cannot switch off.

It exists for good reasons. Hosting companies use it to enforce platform-level behaviour, agencies use it for client-site guardrails, and developers use it for site-specific functions that must survive theme changes. Most WordPress sites have either an empty mu-plugins folder or no folder at all, which is exactly why an unexpected file in there is such a strong signal.

Why attackers love it

Three properties make it near-perfect cover. It loads on every request, which is the whole requirement for persistence. It cannot be deactivated through the interface, so a panicking site owner who disables every plugin does not disable this one. And it does not appear in the normal plugins list at all — the WordPress plugins screen shows must-use plugins in a separate tab that only exists when the folder has files in it, and plenty of owners have never clicked it.

There is a fourth advantage that matters during cleanup: people reinstalling WordPress usually replace core, then plugins, then the theme. The mu-plugins folder is not part of core and is not part of any plugin you would reinstall, so a routine rebuild leaves it completely untouched.

What malicious code there does

The most common role is watchdog. A file in mu-plugins checks on every page load whether the rest of the infection is still present, and rewrites it if not. That is the mechanism behind the maddening experience of deleting an injected script, reloading the site, and finding it back within seconds. You never removed the writer, only its output.

Others provide direct access — a small block of code that grants an administrator session to anyone presenting the right parameter, or silently recreates a deleted admin user. Some simply inject the payload directly, since running on every request means it can add a script to every page without touching the theme at all. My guides on backdoors and reinfection loops cover the wider pattern this fits into.

How to check the folder

Look at wp-content/mu-plugins over FTP, in your host's file manager, or over SSH. Do not rely on the dashboard for this, because the must-use tab only renders files WordPress successfully loaded, and code can be arranged to stay out of that listing.

Then account for every file individually. If your host installs one, you will usually recognize its name and find the same file on other sites with the same host. If a developer added site-specific functions, the code will be readable and obviously related to your site. Anything else — particularly a file with a random or generic name, or code that is encoded rather than written plainly — is your finding. Note that only files at the top level of the folder load automatically, so a subdirectory there is itself a little unusual and worth reading carefully.

Removing it safely

Read the file before deleting it. A minute spent understanding what it does tells you what else to look for — whether it rewrites a specific path, recreates a specific user, or calls out to a specific domain — and that gives you a concrete list to verify later. Copy it somewhere safe first, then delete it.

Delete the watchdog before you clean anything it protects, or it will simply restore what you remove while you work. Once it is gone, do the full pass: replace core, plugins and theme from clean sources, clean the database, audit users, and check scheduled tasks, which are the other favourite persistence spot. Then rotate every credential, because code running with full WordPress privileges could read everything your site can.

Keeping an eye on it afterwards

Once the site is clean, the mu-plugins folder is a genuinely useful early-warning tripwire, because it should almost never change. On most sites it is empty or holds one file from the host, and it stays that way for years. Any new file appearing in it is worth an immediate look.

File integrity monitoring covers this automatically, and so does an occasional manual check. My guide on monitoring and long-term protection covers setting that up. And if you have been through two cleanups and the site keeps rebuilding itself, that persistence chain is exactly what my malware removal service is built to unpick.

Common questions

Where is the mu-plugins folder?

At wp-content/mu-plugins, alongside your ordinary plugins and themes folders. WordPress does not create it by default, so on many sites it simply does not exist — which means its sudden appearance on a site that never had one is itself worth investigating.

Why does nothing show on my plugins screen?

Must-use plugins appear under a separate Must-Use tab that only shows when the folder contains loadable files, and plenty of site owners have never noticed that tab. Code can also be written to keep itself out of that listing. Check the folder on the filesystem rather than trusting the dashboard.

Can I just delete the whole folder?

Only after you have checked what is in it. Some hosts place genuinely required files there, and some developers put site-specific functionality there deliberately — deleting those can break real features. Read each file, work out what it does, and remove what you cannot account for.

Does reinstalling WordPress remove a mu-plugins backdoor?

No, and that is precisely why attackers use it. A core reinstall replaces core files. Reinstalling plugins replaces the plugins directory. Neither touches mu-plugins, so a rebuild that feels thorough can leave the backdoor sitting there loading on every request.

Would a security plugin find this?

Sometimes. Wordfence and similar tools do scan the folder, and a known malicious signature will be caught. But a small custom file, or one that is heavily obfuscated, frequently passes — and because the folder is legitimate WordPress functionality, its mere presence raises no flag. A manual look costs a minute and is worth taking.