A drop-in is a special file in the wp-content folder, such as object-cache.php, that WordPress loads to replace or extend core behavior. It does not appear among normal plugins, so a plugin audit that skips it is incomplete. WP-CLI can list drop-ins with a dedicated status filter.
Definition and how to find them
The WP-CLI handbook for the plugin list command notes that the dropin status lists installed drop-ins, giving object-cache.php as an example. You may find some on a site that you did not write yourself.
wp plugin list --status=dropin
wp plugin list --status=must-use
Together with must-use plugins, drop-ins are the two places a normal inventory is most likely to miss code that runs on every request.
Why they matter for supply chain review
| Type | Where | Shows in normal list? | Gets update notices? |
|---|---|---|---|
| Normal plugin | plugins folder | Yes | Yes, for directory plugins |
| Must-use plugin | mu-plugins folder | Separate section | No, per the handbook |
| Drop-in | wp-content folder | No | No |
Because they run early and for every visitor, a changed drop-in can affect the whole site. They are also easy to forget after a hosting move or a cache plugin removal, which can leave a stale file behind.
An audit checklist
- List drop-ins and must-use plugins on every client site.
- Match each file to a known purpose: caching, platform support, custom code.
- Confirm the source, such as the host's documentation or the cache plugin that created it.
- Add each to the inventory with an owner.
- Check file timestamps and compare with a known good copy when you can.
- Remove stale ones after you confirm nothing depends on them, on staging first.
When to be suspicious
A drop-in with no matching cache or host feature, a recent modification date that matches no deployment, or code you cannot explain are all reasons to investigate. Check them alongside the integrity checks in our posts on plugin checksums and core checksums. Those commands compare against WordPress.org copies, which do not exist for drop-ins, so you need a different reference such as the vendor's package.
After an incident
If a client site was compromised, include drop-ins and mu-plugins in the cleanup, since code can run from them on every request. See the first hour checklist for a compromised client website.
Example
You take over a client site and find an object-cache.php file in wp-content. The cache plugin that created it was removed a year ago. The file is stale. Depending on its contents it may do nothing or cause odd behavior, and either way nobody owns it. Identify its origin, test removal on staging, and then delete it. If the file is host-supplied, leave it alone and add it to the register with the host as owner.
Quick check
Are drop-ins plugins?
They sit outside the normal plugin list, but WP-CLI can list them with the dropin status.
Can I verify them with checksum commands?
Not against WordPress.org, since they are not directory plugins. Compare with the source that created them.
Sources
Last reviewed: 19 October 2026.
