Yes. A deactivated plugin still has every one of its PHP files sitting in wp-content/plugins, and a good number of those files run when a browser requests them directly, whether WordPress loaded the plugin or not. Deactivating stops WordPress from calling the code. It does nothing to stop the internet from reaching it.
Do deactivated WordPress plugins pose a security risk?
They do, for three reasons that have nothing to do with the WordPress admin screen. The files are still present. Many plugin files execute on their own without loading WordPress first. And the vulnerability database does not care what your plugins page says, because automated scanners read your server, not your settings.
When you click Deactivate, WordPress removes the plugin from the active_plugins option. That is it. The folder stays, the PHP stays, and so do the old JavaScript, the sample data, and the bundled libraries from 2019 that nobody has patched since.
Plenty of plugins ship files that bootstrap themselves: AJAX handlers, file upload endpoints, cron scripts, CSV importers, bundled third-party libraries like TimThumb or old versions of PHPMailer. Request one of those URLs and PHP runs it. WordPress never gets consulted about whether the plugin is active.
This is why the same vulnerability disclosure that forces every active install to patch also applies to a plugin you turned off eight months ago and forgot about.
How attackers find a plugin you turned off
They guess the folder name. WordPress plugin slugs are public and predictable, so a scanner walks a list of the 5,000 most common ones and requests a file it knows exists in each. If the server returns 200 instead of 404, the plugin is on disk.
The cheapest fingerprint is readme.txt, which sits in the root of almost every plugin from the official directory and includes a "Stable tag" line with the version number. That one request tells a bot which plugin you have and which release, which is enough to match against a public CVE list. We wrote about why plugin readme.txt files leak version data and what you can do about it; that same leak works identically on inactive plugins.
After the fingerprint comes the exploit attempt, and this is the part people underestimate. A large share of plugin vulnerabilities are reachable through a direct file request or an admin-ajax.php action that the plugin registered. The direct-file ones work on deactivated plugins. Arbitrary file upload bugs in old file manager and slider plugins have been exploited this way for years, long after site owners believed they had "turned the plugin off."
According to Patchstack's State of WordPress Security report, 7,966 new WordPress vulnerabilities were disclosed in 2024, and roughly 96% of those were in plugins (2025). That is not a number you can outrun by deactivating things. Every unpatched copy on disk is one more entry in that pile that happens to be sitting on your server.
Themes are the same problem with worse habits
Nobody audits themes. A site running a custom child theme usually has the parent, plus Twenty Twenty-One, plus whatever premium theme the previous developer bought in 2020 and never removed. Those folders take uploads, contain functions.php, and are a favorite hiding place for reinfection payloads because cleanup tools focus on plugins and core.
If a site keeps getting hit after a cleanup, the leftover theme folder is one of the first places to look. We covered that pattern in detail in why a WordPress site gets hacked again a week after cleanup.
What a dormant plugin costs when it gets hit
The plugin itself costs nothing. The cleanup, the downtime, and the client conversation are where the money goes, and they cost the same whether the breach came through a plugin you rely on or one you forgot to delete.
Emergency malware cleanups are commonly quoted in the $200-$500 range per site for a single incident, and that is before the Google Safe Browsing warning, the reindexing wait, and the hours you spend on the phone. Sucuri's Website Threat Research Report found that a backdoor was present in a majority of the compromised sites they cleaned, which is the mechanism that turns one incident into three (2023).
Run the math for an agency. Forty client sites, an average of three dormant plugins each, and you are maintaining 120 unpatched packages that generate zero value. One breach a year at $400 for cleanup plus six billable hours at $125 is $1,150 before you count the client who starts shopping for a new agency without telling you. Our breakdown of what a WordPress security breach actually costs a business puts real figures on the parts that do not show up on an invoice, and downtime pricing per minute covers the rest.
| Risk source | Present when deactivated? | Typical exploit path | Fix |
|---|---|---|---|
| Plugin PHP files on disk | Yes | Direct request to a standalone script | Delete the folder |
| Known CVE in that version | Yes | Public exploit matched by version fingerprint | Delete or update, then delete |
| readme.txt version disclosure | Yes | Scanner fingerprint, then targeted attack | Delete the plugin |
| Abandoned parent or old theme | Yes | functions.php backdoor, uploader bug | Delete unused themes |
| mu-plugins directory | Always active | Runs regardless of the plugins screen | Audit manually |
| Plugin settings in the database | Yes, harmless alone | None directly | Clean on deletion if offered |
Delete or keep: how to decide in 30 seconds
Delete anything you are not using this month. Keep a full backup instead of keeping the folder. The only plugins worth leaving installed and inactive are the ones you toggle on and off as part of a working routine, and even those should be current.
The reason people hesitate is settings. They think deleting the plugin throws away the configuration. Usually it does not: most plugins leave their options rows in wp_options and their custom tables intact unless you explicitly enable a "remove all data on uninstall" setting. Reinstall later and the settings are often still there.
Cases where keeping an inactive plugin is defensible:
- A seasonal tool you turn on four times a year, like a Black Friday pricing plugin or a holiday banner. Keep it, but update it on the same schedule as everything else.
- A debug or migration utility used during releases, such as Query Monitor or WP Migrate. Keep it current, or better, install it on staging only.
- A licensed plugin you are mid-renewal on. Keep the folder, but confirm the version is patched before it sits there for a quarter.
Everything else goes: the theme you tried for a week, the caching plugin you replaced, the form builder from two redesigns ago, the "coming soon" plugin from launch day. If you need a structured pass across a whole portfolio, our WordPress plugin audit process walks through the inventory step first, which is where most agencies discover how much is installed.
How to delete a plugin without breaking the site
Back up, delete from the admin screen rather than over FTP, then check the front end and one key template. Deleting through the WordPress dashboard runs the plugin's uninstall routine, which cleans up more than dragging the folder to the trash over SFTP does.
The order that keeps you out of trouble:
- Take a full backup, files and database, and confirm you can restore it. A backup you have never tested is a hope, not a plan.
- Do the deletion on staging first if the site earns money. Our guide to WordPress staging environments covers the workflow.
- Delete from Plugins > Installed Plugins so the uninstall hook fires.
- Check for orphaned shortcodes. A deleted plugin leaves its shortcode text sitting in post content, visible as
[some_shortcode]on the page. Search the content table before you delete, not after. - Verify the folder is gone on disk. Some hosts with aggressive file permissions fail the delete and report success anyway.
- Clear caches at every layer, including the CDN.
One exception worth knowing: files in wp-content/mu-plugins load on every request no matter what, and they never appear with an activate or deactivate toggle. If something was dropped there by a previous host or a previous developer, the plugins screen will not tell you. Look at that folder by hand.
Why plugin hygiene stops happening on its own
Nobody forgets on purpose. It stops happening because the task has no deadline, no client is asking for it, and the sites keep loading fine for months while the risk accumulates. Then the site gets defaced on a Saturday and suddenly it is urgent.
This is the same maintenance gap that makes managed WordPress hosting worth the extra cost for most agencies and business owners. The work is not hard, but it is recurring, unglamorous, and the first thing to fall off a busy week.
On TopSyde, file-level scanning runs against the whole tree, not just the plugins WordPress reports as active. TopSyde Sentinel compares what is on disk against known-good plugin and theme releases every day and flags files that should not be there, including modified files inside folders that have been inactive for a year. That is the class of problem signature-only scanners tend to miss, which we covered in how AI-generated WordPress malware evades traditional scanners. Remediation is reversible, so a false positive does not take your site down.
We also keep a running inventory of what is installed across every site in an account, which is how dormant plugins get caught before they become an incident rather than after. Agencies managing a portfolio can see how that fits a multi-client workflow on our agency hosting page, and the technical specifics of the platform live on the spec sheet.
Getting the cleanup done
If you have a site or twenty with plugins nobody has touched since a previous developer left, the fastest path is to let someone else do the inventory. Migration to TopSyde includes a full file audit, and plans start at $89/mo per site with a 30-day money-back guarantee. Support is staffed by people who work on WordPress, with responses under 2 hours during business hours, and monitoring runs 24/7 in the background.
Start with pricing and plan details, or read through the case studies if you want to see how the migration process runs before you commit. If you would rather handle it in-house, delete the plugins you are not using this week. That one pass removes more attack surface than most security plugins add protection.
Frequently Asked Questions
Does deactivating a WordPress plugin stop it from running?
It stops WordPress from loading the plugin during a normal page request. It does not stop a browser or a bot from requesting a PHP file inside that plugin's folder directly, and many plugin files execute on their own when called that way. The code is still on the server and still reachable.
Should I delete plugins I might use again later?
Delete them. Most plugins leave their settings in the database when removed, so reinstalling later usually restores your configuration, and you have a full backup either way. Keeping an unpatched folder on disk for a plugin you might use in six months is a poor trade.
Do deactivated plugins still receive automatic updates?
WordPress can auto-update inactive plugins if auto-updates are enabled for them, but many site owners never turn that on, and premium plugins with expired licenses stop receiving updates entirely. That is how a deactivated plugin ends up sitting at a version with a published exploit for a year or more.
Are unused themes as risky as unused plugins?
Yes, and they get audited far less often. Unused themes contain functions.php and often bundled libraries, they are reachable by direct file request the same way plugins are, and they are a frequent place for a backdoor to survive a malware cleanup. Keep your active theme, its parent if you use one, and one default theme as a fallback.
How do I know if a dormant plugin was already exploited?
Look for files with recent modification dates inside folders you have not touched, unexpected admin users, and outbound spam or SEO injections in your page source. A server-side scan that compares every file against the official release is more reliable than a plugin-based scanner running inside the same WordPress install that may already be compromised.
Founder & Lead Developer
20+ years full-stack development, WordPress, AI tools & agents
Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.
