A file in mu-plugins runs on every request, and you never switched it on.

WordPress reads the must-use plugin directory — wp-content/mu-plugins unless wp-config.php moves it with WPMU_PLUGIN_DIR — and loads every PHP file directly inside it, in alphabetical order, on every request. There is no activation and no deactivation: if the file is there, it runs. Must-use plugins load after the drop-ins and before every ordinary plugin and the theme.

Only files directly in the folder load. A PHP file in a subfolder of mu-plugins runs only if a file at the top level includes it — which is exactly how legitimate must-use setups load larger code, and how a loader can keep its payload one level down where a quick look misses it.

The admin area shows must-use plugins only on a separate Must-Use tab of the Plugins screen, and a must-use plugin can hide that tab entirely with a single filter. The same code can hook the user query so a rogue administrator does not appear on the Users screen, or remove itself from the plugin lists. None of that changes what is on disk.

$ ls -la --time-style=+%F wp-content/mu-plugins
-rw-r--r-- 1 acct acct  1840 2024-03-11 host-cache-purge.php
-rw-r--r-- 1 acct acct   920 2024-03-11 host-staging.php
-rw-r--r-- 1 acct acct  4417 2026-10-12 wp-qa7k2.php
$ grep -cE 'base64_decode|eval|show_advanced_plugins' wp-content/mu-plugins/*.php
wp-content/mu-plugins/host-cache-purge.php:0
wp-content/mu-plugins/host-staging.php:0
wp-content/mu-plugins/wp-qa7k2.php:3

1. 01

   Check whether the folder has been moved

   wp-config.php can point WordPress at a different must-use directory:

   shell

   $ grep -nE 'WPMU_PLUGIN_DIR|WPMU_PLUGIN_URL|WP_CONTENT_DIR' wp-config.php

   If either constant is set, the folder that loads is wherever it points — check that location as well as the default.

2. 02

   List the files that load

   Every PHP file directly in the folder, with full timestamps:

   shell

   $ find wp-content/mu-plugins -maxdepth 1 -type f -name '*.php' -exec ls -la --time-style=full-iso {} +

   Each of these runs on every request. Note the owner, size and modification time of every one.

3. 03

   List what sits in subfolders

   Files below the top level, which load only if a top-level file includes them:

   shell

   $ find wp-content/mu-plugins -mindepth 2 -type f -ls

   A subfolder that belongs to a host or agency tool usually has a top-level loader named after it. A subfolder no top-level file mentions, or hidden files with a leading dot, need explaining.

4. 04

   Read each file’s header

   A legitimate must-use plugin names itself, and usually its author, in a Plugin Name comment:

   shell

   $ head -n 20 wp-content/mu-plugins/*.php

   A file with no header still loads; WordPress simply lists it under its filename. No header, a random name, or one long line of code is a reason to read the whole file.

5. 05

   Search for loader and hiding patterns

   Encoding, indirect execution, and the filters a loader uses to hide itself or an account:

   shell

   $ grep -nE 'eval[[:space:]]*\(|base64_decode|gzinflate|str_rot13|assert[[:space:]]*\(|create_function|show_advanced_plugins|all_plugins|pre_user_query' wp-content/mu-plugins/*.php

   show_advanced_plugins hides the Must-Use tab; all_plugins edits the plugin list; pre_user_query can drop accounts from the Users screen. Legitimate code uses these rarely, and never alongside encoded strings.

1. 01

   Preserve the folder first

   Copy the whole must-use directory, with timestamps, outside the web root, and hash every file:

   shell

   $ mkdir -p ~/incident
   $ cp -pr wp-content/mu-plugins ~/incident/
   $ find ~/incident/mu-plugins -type f -exec sha256sum {} +

   The modification times bound the window everything else in the account gets checked against.

2. 02

   Remove the rogue files

   Delete the top-level loader and anything in a subfolder it included. Leave files your host or agency has confirmed; if you are unsure about one, move it outside the web root rather than deleting it.

3. 03

   Look at the Users screen again

   With the loader gone, any administrator it was hiding becomes visible. Record and remove accounts nobody can vouch for, and check application passwords on the remaining administrators.

4. 04

   Find what wrote it, then rotate

   Something had write access to wp-content. Check the other layers below, then rotate the control panel, SFTP, database and WordPress credentials, and the keys and salts in wp-config.php.

5. 05

   Re-check after a few days

   List the folder again and compare it with the preserved copy. A file that reappears means another persistence layer is still writing it.

A must-use loader is one of several ways to run code on every request without a plugin being switched on, and an infection that uses one usually uses more. In the ClickFix incident documented on this site, the chain lived in obfuscated PHP files, base64 content in the options table, the active theme’s functions.php, and a .user.ini startup directive at the same time.