The last two posts covered PHP itself and who is responsible for which update. This one looks at the layer that is always the site administrator’s job: plugins. We deliberately avoid naming specific plugins, CVE numbers or counts. Figures differ between research firms and change daily, so we point to where you can check them at the end.
A plugin is someone else’s code, running with your site’s permissions
A WordPress plugin runs in the same PHP process, with the same permissions, as WordPress itself. A flaw in a plugin is therefore not limited to that plugin’s feature. It can reach the whole site.
Note: A vulnerability is a defect that lets an outsider make software behave in a way its author did not intend. Not every one leads to harm, but under the right conditions someone can gain administrator rights or place files on the server.
We look at vulnerabilities along three axes, then at the order of response: have less, learn early, patch early.
Axis 1: does exploitation require a login?
| Type | What an attacker needs | How to think about it |
|---|---|---|
| Unauthenticated | Nothing; reaching the URL is enough | Very high. Tried mechanically from everywhere |
| Low-privilege login | e.g. a subscriber account | If registration is open, close to unauthenticated in practice |
| Administrator login | Already being an admin | Lower, though it can chain with other flaws |
Unauthenticated flaws weigh the most because the only precondition is that the plugin is installed. How careful you are elsewhere does not matter. Note too that if your site lets anyone register, “low-privilege” flaws are effectively open to everyone.
Axis 2: how fast attempts follow disclosure
When a fix is published, the difference between versions also shows what was fixed. Security vendors report that automated attempts tend to rise soon after disclosure. We do not quote a number because the figures vary by study; Patchstack states on its own site that new vulnerabilities are being mass exploited in “just hours” (checked 2026-10-30).
The practical takeaway: a “update everything once a month” routine can leave too wide a window for critical unauthenticated issues. Keep an exception for those.
Axis 3: is the vulnerable code still on the server?
Deactivating a plugin does not remove its files. Depending on how a flaw works, the files can sometimes be requested directly even when WordPress is not loading them. “We don’t use it” is not the same as “it can’t be reached.” The safer default is not to keep what you don’t use.
Deactivated plugins also tend to be forgotten: update notices are easy to overlook and the code ages quietly. What remains is attack surface with no owner.
An inventory, starting read-only
# Deactivated plugins
wp plugin list --status=inactive
# Plugins with updates available
wp plugin list --update=available
# Everything, with status, version and update flag
wp plugin list --fields=name,status,version,update
Then decide:
- Deactivated and lingering: if there is no concrete plan to use it, mark it for deletion
- Updates available: read the changelog for security-related notes and prioritise those
- Not updated for a long time: the author may have stopped maintaining it; look for an alternative or question whether you need the feature
- Overlapping functions: merge where you can, to reduce the count
Always take a backup first. Deletion cannot be undone, so the order is backup, check, delete.
# Example, one at a time, after a backup
wp plugin delete <plugin-slug>
The same applies to unused themes, apart from a parent theme that is still needed.
Where to learn early
- Wordfence Intelligence (vulnerability database and weekly reports)
- Patchstack vulnerability database
- Each plugin’s changelog on WordPress.org
Search for the plugins you actually run, or use a notification service. Remember that all of this is information after disclosure; some issues are exploited before that, which is why reducing the number of plugins matters.
Check the line of responsibility
As the previous post set out, plugins belong to the site administrator, not the hosting provider. If automatic updates are off, a notice changes nothing. When you manage several sites, keep a table of installed plugins, update status and auto-update settings so you can find the affected sites quickly.
Summary
- Plugins run with the site’s permissions, so a flaw can affect the whole site
- Unauthenticated flaws need only “installed” as a precondition, so treat them as heaviest
- Deactivating leaves files behind; delete what you don’t use
- Start with the read-only
--status=inactiveand--update=availablelists - Back up before deleting, and decide where you will check disclosures
One step you can take today: run wp plugin list --status=inactive once and read the list. It will likely show your first candidates for reducing attack surface.