A must-use plugin, or mu-plugin, is a PHP file in the wp-content/mu-plugins folder that WordPress loads automatically on every request. It cannot be turned off from wp-admin and does not get update notices. Because of that, each one needs a named owner, a reason to exist, and a manual update routine.
What the handbook says
The WordPress Advanced Administration Handbook defines mu-plugins as plugins installed in a special directory inside the content folder that are enabled on all sites in the installation. They show in a separate Must-Use section on the Plugins screen, not the default list. To disable one you remove its file.
Hosts commonly use them for platform features. Agencies use them for site-specific bootstrap code. Both are fine uses, and both create risk if nobody tracks them.
Why they matter for supply chain risk
The handbook lists caveats that read like an audit checklist:
- Must-use plugins do not appear in update notifications and show no update status, so you must learn about and perform updates yourself.
- Activation hooks do not run for them.
- WordPress only loads PHP files directly inside the folder, not in subfolders, unless you add a small loader file.
- They load alphabetically before normal plugins.
The handbook's own maintenance note is blunt: a compromised mu-plugin can be harder to notice than a normal plugin because it cannot be disabled from the main plugins list. Keep them small, reviewed and documented.
A register for mu-plugins
For every client site, record:
| Field | Example question |
|---|---|
| File name | What exactly is in the folder? |
| Purpose | Why does this need to always run? |
| Source | Host-supplied, agency-written or third-party? |
| Owner | Who updates it and who reviews changes? |
| Update path | How will we hear about a new release? |
If the answer to owner is nobody, either assign one or remove the file.
Steps to audit today
- List them with the plugin list command and the must-use status filter.
- Open each file and read it. They are usually short.
- Compare any host-supplied files with the host's documentation.
- Add each to your inventory so advisories can be matched.
- Review the folder again after any hosting migration, since files can arrive or vanish.
Composer users should note that tools such as the wpackagist repository can install a package into the mu-plugins folder through installer paths, so a Composer file can be the source of truth for some of them.
A common failure case
An agency inherits a site from another team. The migration copied a mu-plugins folder nobody mentioned. Months later a host change breaks the site, and no one knows that one of those files adjusted caching and another registered a custom login redirect. Because the files never appeared in the normal list, no update notice ever arrived either. The fix is boring: a register, an owner, and a note in the handover document. Make the register a required item whenever you take over a client site.
Quick check
Are mu-plugins safer because users cannot disable them?
No. They are harder to remove by accident, but also harder to notice if compromised, and they skip update notices.
Can wp-admin delete one?
No. You remove the file from the mu-plugins folder.
Sources
- Must-Use Plugins, WordPress Advanced Administration Handbook
- wp plugin list, WP-CLI handbook
- Wpackagist
Last reviewed: 19 October 2026.
