The Hidden Plugin Trick: How Attackers Hide Malware From Your Plugin List

Ask most WordPress site owners how they’d check for a malicious plugin, and the answer is almost always the same: look at the Plugins page in wp-admin. That instinct is reasonable — and it is exactly the assumption a specific, well-documented attack technique is built to exploit.

The all_plugins filter

WordPress runs every plugin’s entry through the all_plugins filter before rendering the Plugins page. This filter exists for legitimate reasons — a few plugin management tools use it to relabel or reorganize the list. But nothing stops a malicious plugin from hooking that same filter and simply removing its own entry from the array before it reaches the screen, every single time an administrator loads the page.

The result: the plugin is fully active, its code runs on every request, but it is invisible in wp-admin’s Plugins list, invisible in the plugin count on the dashboard, and invisible to any security tool that builds its plugin inventory by calling WordPress’s own get_plugins() function or scraping the same admin screen.

Why this works against most scanners

The overwhelming majority of WordPress security plugins and scanners check "what plugins are installed" by asking WordPress the same question an administrator would ask — through the exact API surface this technique targets. If the attacker controls the plugin, and the plugin controls what that API reports, the scanner and the administrator see the same lie.

The one check that actually catches it

The plugin still has to exist as real PHP files inside wp-content/plugins/ for WordPress to load and execute it — that part cannot be hidden. The fix is comparing two independent sources of truth on every scan: what folders are physically present on disk, and what WordPress’s own plugin API reports as installed. A folder that exists on disk but never appears in the API response is exactly the fingerprint this technique cannot avoid leaving behind.

It gets worse: must-use plugins

Files dropped directly into wp-content/mu-plugins/ load automatically before regular plugins and never appear in the standard plugin list at all — no filter hook required, because WordPress simply doesn’t show must-use plugins the same way. Any inventory check that only scans the regular plugins/ directory misses this entirely.

Takeaway

A plugin list that only reflects what WordPress chooses to report is not an inventory — it’s a self-report from a system that, in a real compromise, the attacker also controls. Real inventory checking means looking at the filesystem directly, independent of anything the WordPress install itself can filter or hide.

This exact disk-vs-database mismatch is the core detection technique behind WPGuard's inventory scanning — the full technical model, including how signed agent check-ins prevent a compromised site from lying about its own state, is on the Security page.