Start with the problem you are seeing
Could this match the problem on your WordPress site?
This entry is relevant when a plugin repeatedly disappears or deactivates and an unfamiliar media-named PHP file is present in mu-plugins. The two observations occurred in one investigation, but the retained evidence does not prove causation.
Observed in this investigation
- The investigation retained a suspicious media-named file in the must-use plugin directory alongside reports of a plugin disappearing or deactivating.
Possible warning signs
- An affected plugin may appear to deactivate or disappear again after being restored.
- The suspicious MU-plugin file may not be obvious in the ordinary Plugins list.
These signs are investigation leads, not proof of this artifact by themselves.
Questions this research can help answer
- Why does a WordPress plugin keep disappearing or deactivating?
- Could an unfamiliar MU-plugin file be related to recurring plugin changes?
Evidence boundary: The artifacts shared an investigation context, but a direct mechanism linking the MU-plugin file to the reported plugin symptom was not confirmed.
Seeing one of these signs on your site?
I can investigate the files, database records, users, and server evidence, explain what is confirmed, and help plan a safe cleanup.
Research focus: Forensic review of a media-patcher-lab.php MU-plugin artifact associated with obfuscated plugin-management code and transient loaders.
Summary
This WordPress malware research entry documents fake mu-plugin with plugin tampering evidence observed during one anonymized client investigation. The narrow topic is media-patcher-lab.php Found in WordPress mu-plugins: the page records the exact artifact, identifiers, and visible control flow instead of repeating a general malware-removal article.
The combined artifacts are consistent with persistent plugin tampering and redundant access. The reported Amelia symptom is plausible context, but no retained event log directly links media-patcher-lab.php to removal of Amelia.
Investigation context
Anonymized investigation with two screenshots and representative fake-plugin plus transient-loader samples. The report date is retained from the original investigation notes. Broader cleanup guidance remains in the WordPress malware removal guide; this entry is limited to what the supplied code and screenshots support.
Observed artifact
media-patcher-lab.php existed in the MU-plugin directory.

Confirmed findings
- media-patcher-lab.php was present under wp-content/mu-plugins.
- The representative sample uses a fake plugin identity.
- Related retained strings resolve WordPress plugin-management functions.
- Separate small samples stage decoded request data in temporary PHP files and then delete them.
Technical analysis
Why the MU-plugin location matters more than the symptom
The following code keeps the identifiers and control flow needed for defensive verification while removing secrets, complete payloads, and operational request instructions.
Redacted defensive excerpt
/** Plugin Name: Media Patcher Lab */
// obfuscated string table resolves plugin-management functions
$targets = request_plugin_identifiers();
foreach ($targets as $plugin) {
inspect_or_change_plugin_state($plugin);
}
// request names and destructive helper bodies redacted
This excerpt is intentionally incomplete. It should be used for code search, baseline comparison, and incident review—not copied into a live site.
Analyst assessment
The combined artifacts are consistent with persistent plugin tampering and redundant access. The reported Amelia symptom is plausible context, but no retained event log directly links media-patcher-lab.php to removal of Amelia.
The severity reflects the capability visible in this artifact and its position in the investigated WordPress environment. It is not a claim about campaign prevalence, a particular vulnerability, or an outcome that the retained evidence does not show.
Indicators of compromise
Higher-confidence indicators
media-patcher-lab.phpMedia Patcher Lab identity in mu-pluginsmenu-queue-bit.php / Dev Scanner Ink in related evidence
Contextual indicators
mu-pluginsdeactivate_plugins()active_plugins optionA legitimate plugin failing to remain active
Contextual indicators are not proof of infection by themselves. Confirm them through trusted-file comparison, neighboring code, database provenance, request logs, or the distinctive combinations listed above.
What this evidence does not establish
- The evidence does not establish an Amelia vulnerability.
- The Plugins-screen screenshot is excluded because it shows only the plugin state, not the removal mechanism.
- The initial compromise method and exact relationship among all representative files were not confirmed.
- Operational request parameters and complete loaders are withheld.
Artifact-specific remediation
- Preserve the MU-plugin and representative related files.
- Remove untrusted MU plugins before reinstalling affected legitimate plugins.
- Review active_plugins and related options after file cleanup.
- Search for the fake identities and transient-loader structure across the account.
For a complete response sequence, use the broader malware-removal guide or the WordPress malware-removal service when hands-on incident response is appropriate.
Recurrence verification
- Confirm media-patcher-lab.php does not return.
- Monitor plugin state and MU-plugin filesystem changes together.
- Verify legitimate plugins remain stable after malicious persistence is removed.
Related malware research
Browse the WordPress malware research hub.
- menu queue bit compact extension vox
- system-control Plugin Restored from wp-content/.sc-backup
- StateMesh MU-Plugin Self-Copy and Plugin-List Concealment
Related guides and case studies
Methodology and privacy note
This analysis is based on retained code, screenshots, paths, and notes from an anonymized WordPress client investigation. Confirmed findings are limited to visible or supplied evidence; professional interpretation is labeled as analyst assessment. Screenshots were reviewed for client identifiers, account paths, usernames, email addresses, credentials, tokens, database details, and unrelated records. Sensitive or operational material remains outside the public page, and every public code block is a redacted defensive excerpt.