A drop-in loads before every plugin, needs no activation, and is easy to overlook.

A drop-in is a file with a reserved name, placed directly in wp-content, that WordPress loads by itself to replace or extend part of its own behaviour. There is no activation step and no setting in the admin area. If the file exists — and, for advanced-cache.php, if the WP_CACHE constant is true — it runs on every request, before must-use plugins, ordinary plugins and the theme.

The legitimate uses are common. Page-caching plugins write advanced-cache.php so a cached page can be served before most of WordPress loads; object-cache plugins write object-cache.php to connect WordPress to Redis or Memcached; database plugins, and debugging tools such as Query Monitor, use db.php. That familiarity is the attraction: a file called object-cache.php reads as infrastructure, and most people who find one assume a plugin put it there.

Drop-ins do not appear in the ordinary list of plugins. WordPress shows a separate Drop-ins tab on the Plugins screen when any exist, which most owners never open. And because a drop-in loads before every security plugin, a loader there runs before anything that might notice it.

Diagram · Where drop-ins and must-use plugins sit

Drop-ins live loose in wp-content, by exact name. Nothing activates them.

wp-content/in the order WordPress reaches each part on a request

• advanced-cache.phpDrop-in: loaded first when WP_CACHE is true in wp-config.php
• db.phpDrop-in: replaces the database class whenever the file exists
• object-cache.phpDrop-in: replaces the object cache whenever the file exists
• index.phpThe empty “Silence is golden” file, not a drop-in
• mu-plugins/Must-use plugins: every PHP file directly inside loads, no activation
• plugins/Ordinary plugins: only those in the active_plugins option load
• themes/The active theme’s functions.php loads after all of the above
• uploads/Media; PHP here is never loaded by WordPress itself

• Loads before any plugin, without being activated

Figure 1 · The drop-ins, and what makes one suspicious

Every drop-in has a legitimate owner. A loader under the same name has none.

Drop-in	Loads when	Normally written by	Suspicious if
advanced-cache.php	WP_CACHE is true	A page-caching plugin	No caching plugin installed
object-cache.php	The file exists	An object-cache plugin or host	A few lines, encoded strings
db.php	The file exists	A database plugin, Query Monitor	Includes a file outside a plugin
maintenance.php	Maintenance mode	A custom maintenance page	Any code beyond a message
sunrise.php	Multisite, SUNRISE set	Domain-mapping code	Present on a single site

1. 01

   List every PHP file directly in wp-content

   With full timestamps, so a file written during the incident stands out from the rest:

   shell

   $ ls -la --time-style=full-iso wp-content/*.php

   index.php is normal. Anything else is a drop-in candidate; note its owner, size and modification time.

2. 02

   Check whether page caching is switched on

   advanced-cache.php only loads when WP_CACHE is true:

   shell

   $ grep -n 'WP_CACHE' wp-config.php

   WP_CACHE true with no page-caching plugin installed means something set it — and a caching plugin you removed long ago can leave both the constant and the file behind.

3. 03

   Read the header of each drop-in

   A drop-in written by a plugin names that plugin in its opening comment and usually loads code from the plugin’s own folder:

   shell

   $ head -n 25 wp-content/advanced-cache.php wp-content/object-cache.php wp-content/db.php 2>/dev/null

   Check that the plugin it names is actually installed in wp-content/plugins. A drop-in that names no plugin, or a plugin that is not there, has no owner.

4. 04

   Search the drop-ins for loader patterns

   Encoding, indirect execution and request parameters that should never appear in a cache or database layer:

   shell

   $ grep -nE 'eval[[:space:]]*\(|base64_decode|gzinflate|str_rot13|assert[[:space:]]*\(|create_function|\$_(POST|GET|REQUEST|COOKIE)' wp-content/*.php

   A caching drop-in may legitimately read cookies to decide whether to serve a cached page. Encoded strings and eval have no such explanation.

5. 05

   Look for a symbolic link

   Query Monitor’s db.php, and some caching setups, are symbolic links into a plugin folder rather than copies. ls -la shows the target after an arrow; a link into a plugin you can name is explainable, a link anywhere else is not.

1. 01

   Preserve the file first

   Copy every drop-in you are about to change, with its timestamps, outside the web root, and hash it:

   shell

   $ mkdir -p ~/incident
   $ cp -p wp-content/*.php ~/incident/
   $ sha256sum ~/incident/*.php

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

2. 02

   Remove the rogue file

   Delete the drop-in that no installed plugin owns. If it was advanced-cache.php and no page-caching plugin is installed, also set WP_CACHE back to false, or remove the line, in wp-config.php.

3. 03

   Let a legitimate plugin rewrite its own drop-in

   If the name belongs to a caching or database plugin you do use but the content was replaced, delete the file and let the plugin regenerate it from its own settings screen, or deactivate and reactivate the plugin — never edit the drop-in back by hand.

4. 04

   Check db.php before deleting it

   A db.php from a multi-database plugin is load-bearing: removing it can take the site offline if the setup depends on it. Confirm what the plugin expects before deleting a db.php that turns out to be legitimate.

5. 05

   Find what wrote it, then rotate

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

6. 06

   Re-check after a few days

   List wp-content/*.php again and compare against the preserved copy. A drop-in that reappears means a persistence layer is still writing it.

A drop-in is one way to run code early without being activated. The same infection usually has others, and any one of them can write the drop-in back. In the ClickFix incident documented on this site, the chain lived in four layers at once: obfuscated PHP files, base64 content in the options table, the active theme’s functions.php, and a .user.ini startup directive.