Muhammad Basim
WordPress

Auditing WordPress Plugins for Security Risk

By Muhammad Basim·

WordPress core is not your security problem.

Patchstack's State of WordPress Security in 2026 recorded 11,334 new vulnerabilities across the WordPress ecosystem during 2025 — and two of them were in core. Ninety-one percent were in plugins.

So the most useful security question isn't "which security plugin should I install." It's "which of the twenty-three plugins I already have is going to be the one."

Here's how to find out.

The short version

Five signals a plugin is a liability:

  1. Not updated in over a year — abandonment
  2. A known unpatched vulnerability in your installed version
  3. Very few installs relative to its age — little scrutiny
  4. Nulled or pirated — assume it's compromised
  5. Doing far more than you need — unnecessary attack surface

Check them against: the WPScan Vulnerability Database, Patchstack's database, and each plugin's WordPress.org page.

Why plugins specifically

Worth understanding the structural reason, because it explains why this won't change.

WordPress core is developed in the open by thousands of contributors with an established security process and a dedicated team. The code gets reviewed heavily.

Plugins are built by tens of thousands of independent developers with no standardised security review. Some are excellent. Many are written by people solving their own problem who never expected 40,000 installs. Some are abandoned the moment the developer's circumstances change.

That's not a criticism of the ecosystem — it's what makes WordPress extensible. But it does mean every plugin you install is a separate trust decision about a separate developer, and most people make twenty of those decisions without noticing they've made any.

Signal 1 — Abandonment

The most common and most checkable.

Where to look: each plugin's page on WordPress.org shows "Last updated" and "Tested up to."

What's a problem:

Over a year without an update. The plugin may work fine — but if a vulnerability is found in it, nobody is going to fix it.

"Untested with your version of WordPress." Sometimes just a lazy header update, sometimes genuine abandonment. Check the support forum for recent developer replies.

A support forum full of unanswered threads from months ago. That's the clearest signal, because it shows nobody is home.

Inactive plugins count. A deactivated plugin is still files on your server. If it has a vulnerability, having it deactivated doesn't always help — some vulnerabilities are exploitable in files that are directly accessible regardless of activation state. Delete what you don't use, don't just deactivate it.

The same applies to themes. An unused theme sitting in your install is the same risk as an unused plugin, and people forget themes entirely.

Signal 2 — Known vulnerabilities

Where to check:

WPScan Vulnerability Database (wpscan.com/plugins) — searchable by plugin, showing disclosed vulnerabilities and affected version ranges.

Patchstack's database (patchstack.com/database) — same purpose, different research team.

Your security plugin. Wordfence, Patchstack, and Solid Security all monitor your installed plugins against vulnerability feeds and alert you. This is the practical version of doing it manually, and it's the main reason to run one.

What you're looking for: a disclosed vulnerability affecting the version you have installed, without a patch, or with a patch you haven't applied.

The uncomfortable context: Patchstack found 46% of vulnerabilities disclosed in 2025 had no developer patch available at disclosure. Nearly half were made public while the plugin remained unfixed. So "is there an update available" isn't the whole question — sometimes there isn't one, and your options are removing the plugin or using a service that provides virtual patching.

Signal 3 — Very low install counts

Not a hard rule, and worth thinking about proportionally.

A plugin with 200 active installs after five years has had very little scrutiny. Fewer people using it means fewer people finding problems, and less incentive for security researchers to look.

That doesn't make small plugins bad. A well-written plugin from a developer you can identify, doing one narrow job, is often safer than a bloated popular one. The signal is really about combined risk: low installs plus no recent updates plus no identifiable developer is a pattern worth acting on.

What to weigh instead of raw numbers: is the developer identifiable and active elsewhere? Does the plugin have a real support presence? Is it maintained by a company with something to lose?

Signal 4 — Nulled and pirated plugins

Direct: assume a nulled plugin is compromised.

"Nulled" versions are paid plugins redistributed with their licence checks removed. The business model of the sites distributing them is not charity — the common pattern is injecting backdoors, and you've installed it yourself with full file access.

There is no safe way to use one. If you can't afford a premium plugin, use a free alternative.

Same applies to themes, and to "free download" sites offering premium products.

Signal 5 — Excessive scope

A subtler consideration.

A plugin that does one narrow thing has a small attack surface. A plugin suite doing forty things — with an admin panel, an API, file upload handling, and user-facing forms — has a much larger one, and you're exposed to all of it even if you use one feature.

Worth asking: could a much smaller plugin, or ten lines in a child theme, do the job? A page builder addon pack loading sixty widgets so you can use one is a performance problem and a security surface. The performance side.

Also worth checking: whether the plugin has a module system letting you disable what you don't use. Many do, and most people never look.

Running the audit

Half an hour, once a quarter.

1. List everything. Plugins → Installed Plugins, active and inactive. Themes too.

2. Delete what you don't use. Inactive plugins, unused themes. Immediate risk reduction, no downside.

3. Check "Last updated" on each remaining one. Flag anything over a year.

4. Search each flagged plugin in WPScan or Patchstack for disclosed vulnerabilities.

5. For anything abandoned or vulnerable, decide: find a maintained alternative, remove it and live without the feature, or — if it's genuinely essential and unmaintained — accept the risk knowingly and put virtual patching in front of it.

6. Record what you decided. Six months from now you won't remember why you kept the risky one, and a note saves you re-deciding.

The prevention habit

Before installing anything new, thirty seconds:

  • When was it last updated?
  • How many active installs, relative to how long it's existed?
  • Is the developer identifiable and active?
  • Does the support forum show recent replies?
  • Do I actually need this, or is there a lighter way?

That check prevents more incidents than any plugin you could install.

Frequently asked questions

How do I know if a plugin is abandoned?
Check its WordPress.org page for "Last updated" and "Tested up to." Over a year without an update is the main signal, and an unanswered support forum is the clearest confirmation — it shows nobody is maintaining it regardless of what the version number says. An abandoned plugin may work perfectly today; the risk is that when a vulnerability is found, nobody will fix it.

Are free plugins less safe than premium ones?
Not inherently, and the assumption can mislead. Patchstack's 2026 data found that 76% of vulnerabilities in premium WordPress components were exploitable, with premium components showing roughly three times as many known exploited vulnerabilities as free ones in its telemetry — though Patchstack sells vulnerability protection, so weigh that accordingly. What actually predicts safety is maintenance: an actively updated free plugin from a responsive developer beats an abandoned premium one. Nulled or pirated versions of premium plugins are a separate category entirely and should be assumed compromised.

Where can I check plugin vulnerabilities?
The WPScan Vulnerability Database and Patchstack's database both let you search by plugin name and see disclosed vulnerabilities with affected version ranges. Security plugins including Wordfence, Patchstack, and Solid Security monitor your installed plugins against these feeds automatically and alert you, which is the practical version for ongoing use rather than manual checking.

What to do next

Open Plugins → Installed Plugins and delete every deactivated plugin.

That's a free security improvement in about two minutes, with no downside — deactivated plugins are still files on your server, and having them switched off isn't reliable protection.

Then check the "Last updated" date on the remaining ones. Anything over a year is where your exposure is concentrated.

Free: The WordPress maintenance checklist.


Related guides

Join the Newsletter

Get practical marketing tactics delivered straight to your inbox.

Muhammad Basim

Written by

Muhammad Basim

Related Articles

Newsletter

Free: The 60-Minute
Email Authentication Fix

A no-fluff checklist from the Deliverability Playbook. In one hour: set up SPF, DKIM & DMARC correctly, check your domain against blocklists, and pass Gmail & Yahoo's 2026 sender requirements.

No spam — that would be ironic. Unsubscribe anytime.