What matters first: Code under wp-content/mu-plugins executes on every request before normal plugins and may be represented by only a small loader in the dashboard.
What this symptom actually tells you
Attackers use this location because site owners often inspect only the standard plugin list. Legitimate hosts and agencies also use it, so provenance matters.
Capture evidence before changing anything
- List every file and subdirectory under mu-plugins with hashes and timestamps.
- Open loader files and trace all required or included paths.
- Compare the directory with hosting, agency and deployment documentation.
- Search for remote requests, user creation, file writes and conditional execution.
Most common causes
- Malicious loader: A small file includes a hidden payload elsewhere.
- Compromised legitimate MU plugin: Trusted operational code was modified.
- Host-managed functionality: A valid platform plugin is undocumented locally.
- Persistence bridge: The MU plugin restores normal-plugin or theme malware.
Safe diagnostic and repair sequence
- Preserve copies and verify ownership before removal.
- Confirm legitimate host functions so cleanup does not break caching or platform controls.
- Remove malicious loaders and every referenced payload.
- Audit server config, cron and database for additional early-execution persistence.
How to choose between the likely causes
Do not treat Malicious loader and Compromised legitimate MU plugin as interchangeable. A small file includes a hidden payload elsewhere. By contrast, trusted operational code was modified. Use two checks to separate them: List every file and subdirectory under mu-plugins with hashes and timestamps; and open loader files and trace all required or included paths. Those observations usually show whether the next safe move is to preserve copies and verify ownership before removal or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not delete all mu-plugins on managed hosting. You can disable critical platform security, caching or routing and make recovery harder.
How to verify the repair
- Every MU plugin has a documented owner and purpose.
- No hidden include path or malicious behaviour remains.
- The site works through restart, cron and cache cycles without reinfection.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Attackers use this location because site owners often inspect only the standard plugin list. Legitimate hosts and agencies also use it, so provenance matters.
- 1
List every file and subdirectory under mu-plugins with hashes and timestamps.
- 2
Open loader files and trace all required or included paths.
- 3
Compare the directory with hosting, agency and deployment documentation.
- 4
Search for remote requests, user creation, file writes and conditional execution.
What must be verified
- Every MU plugin has a documented owner and purpose.
- No hidden include path or malicious behaviour remains.
- The site works through restart, cron and cache cycles without reinfection.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is every file inside mu-plugins suspicious by default?+
No. Managed hosts and agencies legitimately use must-use plugins for caching, routing and platform controls, so the location alone is not evidence of compromise. What matters is whether each file has a documented owner and purpose you can verify against hosting or deployment records.
Why doesn't a malicious mu-plugin show up when I scan the plugin list?+
Must-use plugins execute automatically on every request and are not listed or toggled in the standard Plugins screen, so tools and admins that only check that screen miss them entirely. A small loader file in mu-plugins can also include a hidden payload stored elsewhere, so the dashboard shows nothing unusual even when the site is compromised.
Is it safe to just delete the whole mu-plugins folder to be sure?+
No, this is explicitly a mistake on managed hosting. Deleting everything in mu-plugins can disable critical platform security, caching or routing functionality and make recovery harder rather than easier.
If I remove the malicious loader, is the site clean?+
Not necessarily. A mu-plugins backdoor is often a persistence bridge that restores malware in normal plugins or theme files, so removing only the loader without auditing server config, cron jobs and the database for other early-execution persistence can leave the site reinfected.