Inactive WordPress Plugins: Security Risk and Removal Guide

An inactive plugin is code on the server that can still be exploited. Here is how to decide what to remove and do it safely.

The assumption that "an inactive plugin is safe because it does not run" is wrong. The plugin's code still sits on the server, and many vulnerabilities are exploitable without the plugin being active - via exposed AJAX endpoints, REST routes registered at install time, or leftover .htaccess rules.

Why this matters

WordPress vulnerabilities are published openly via CVE databases and WPScan. Bots crawl the internet looking for vulnerable WordPress sites and check whether specific files of a given plugin exist at a known path - they do not check whether the plugin is active. The classic example: an RCE in File Manager that simply looked for /wp-content/plugins/wp-file-manager/lib/php/connector.minimal.php. The scanner did not care about activation status. An inactive plugin is not an unreachable plugin.

On top of that, old plugins that were not updated for the current PHP or WordPress can produce errors even when not running. And finally, every installed plugin is a link in a chain of trust: installing a plugin creates a relationship with its developer, who might be compromised and ship a malicious update (supply-chain attacks have hit large plugins in the past).

How to detect

Visit Plugins > Installed Plugins and filter by Inactive. The list shows everything installed that is not currently active. RankPlus scans get_plugins() and compares to get_option('active_plugins') to identify them. Via WP-CLI:

wp plugin list --status=inactive --format=table

How to fix

  1. Go through the list. For each plugin ask: will I use this in the next six months?
  2. If no, delete it. You can always reinstall from the directory later.
  3. If yes but not right now, ask why it is inactive. If it broke something, it likely will not start working spontaneously.
  4. On the Plugins page tick the boxes you want to remove, open Bulk actions and pick Delete. A confirmation appears.
  5. Check whether the plugin created its own DB tables. Some plugins ship a "clean uninstall" that drops them; for others you must drop manually: wp db query "SHOW TABLES LIKE 'wp_pluginname_%'".
  6. Clean leftover entries from wp_options: SELECT * FROM wp_options WHERE option_name LIKE '%pluginname%' and remove anything orphaned.

Common mistakes

  • Keeping a plugin "to evaluate later" for a year - risk accumulates.
  • Deleting without checking dependencies: some plugins depend on others (WooCommerce + Subscriptions). Removing the parent fatal-errors the dependent.
  • Deleting via FTP only instead of through wp-admin: this skips uninstall.php, leaving tables and options behind.
  • Forgotten mu-plugins: wp-content/mu-plugins/ always runs. Anything dropped there long ago is still live. Check that folder.

Verifying the fix

Run wp plugin list --status=inactive again - only the entries you intended should remain. RankPlus turns green. Verify the site still works: load the home page and a random post - nothing should break from removing genuinely inactive plugins. If something does break, the plugin was not truly inactive.

Tip: Take a full backup before bulk deletions. Most of the time inactive-plugin removal is harmless, but some uninstall.php scripts are aggressive (dropping tables, deleting options) and recovery is non-trivial.