The ordinary WordPress plugin list is not the complete picture of a website’s installed functionality. Must-use plugins, often called MU plugins, deserve attention during a security review too.
In a Peonixis investigation, this layer contained a suspicious component called MailPoint1360. Its relationship to a returning fake plugin helped explain why deleting the visible symptom had not resolved the incident.
Understanding MU plugins makes that finding easier to interpret. It also helps website owners ask better questions about the code running on their installations.
What is a WordPress MU plugin?
WordPress automatically loads MU plugins from a special directory, normally wp-content/mu-plugins. They appear in a separate Must-Use section rather than the default plugin list. They do not have the ordinary dashboard deactivation control; disabling one requires handling its file or loader appropriately. Reference: WordPress MU plugin documentation.
This is legitimate WordPress functionality. Hosts and developers use it for features that should remain available, such as platform integrations or site-specific behaviour.
The presence of an MU plugin therefore does not establish a compromise. The relevant questions are who supplied it, why it exists, and what it does.
Why ownership matters
A website owner may be familiar with plugins they installed personally while knowing little about components introduced during hosting setup or development.
A practical inventory should connect each MU plugin with its purpose and maintainer. If a component cannot be explained, that uncertainty is a reason to investigate, rather than a reason to delete the whole directory.
Removing a legitimate integration without understanding its role could disrupt the website. A careful review separates expected functionality from unauthorised changes.
What happened in the MailPoint1360 investigation?
During routine maintenance, Peonixis noticed a fake plugin named Resilient Backup. Deleting it made it disappear, but it returned when checked again.
The investigation moved below the normal plugin screen and identified MailPoint1360 as a suspicious MU plugin. The case study describes it as part of the underlying mechanism connected with the returning fake plugin.
Once that component was addressed, the fake plugin could finally be removed successfully. The team also identified an associated database script, hidden gambling-related posts, and an attacker-created user.
The article’s wording about deactivation should not be read as suggesting that an MU plugin has a normal dashboard Deactivate button. The public case study does not specify the file-level procedure used.
What a useful MU plugin review should answer
A review should produce an explanation, not just a list of unfamiliar filenames. Useful questions include:
- Who introduced each component?
- Is its purpose documented by the host or developer?
- Does the installed code match the expected component?
- Can it explain the unwanted behaviour under investigation?
- What site functions depend on it?
The scope should reflect the observed incident. In this case, the question was why a fake plugin kept returning, and the MU plugin finding helped answer it.
Keep the finding in proportion
MailPoint1360 is a name reported in this particular incident. The screenshots do not establish a widely documented malware family, a specific public vulnerability, or a pattern affecting every WordPress website.
Likewise, this case does not make MU plugins inherently unsafe. It shows why investigators should examine the relevant layers of an installation instead of limiting a review to the most familiar dashboard view.
Read the complete case study and our related article, WordPress Plugin Keeps Reinstalling Itself? What to Investigate, for the context behind the discovery.
