How to check whether a WordPress plugin has a known vulnerability

Knowing that a plugin you run has a published flaw is worth more than any scanner, because it lets you act in the window before bots start exploiting it. That window is usually days.

Here is how to check, and what the answer actually means.

The databases worth using

WPScan maintains the largest WordPress-specific vulnerability database. The web interface is free to search, and the API has a free tier of around 25 requests a day. This is the one most tools are built on.

Patchstack runs a similar database with a public vulnerability list and a free browsing interface. Their disclosures are often quick.

The WordPress.org plugin page itself is worth a look for a different reason: if a plugin has been closed, the page will say so. A closed plugin means the directory removed it, frequently for a security problem, and it will never be updated again.

The National Vulnerability Database carries CVE entries, useful for a formal reference but slower and less WordPress-specific.

Checking a specific plugin

1. Find the slug — the folder name in wp-content/plugins, which is also the last part of its wordpress.org URL
2. Find your installed version — Plugins → Installed Plugins in the admin
3. Search the slug on WPScan or Patchstack
4. Compare against "fixed in" — this is the part people get wrong

That last step matters. A vulnerability listed as fixed in 5.9.3 affects every version below 5.9.3. If you are on 5.8.1, you are affected, even though the listing is about a newer release.

Checking everything at once

Doing this by hand for twenty plugins is not sustainable. Options:

• Our free plugin does exactly this — it checks every installed plugin against the live database and tells you which are affected, with the fixed version. No account, no API key. Get it here.
• Wordfence and Patchstack both offer free plugins that scan against their own databases.
• The WPScan API directly, if you would rather script it.

Whichever you use, the value is not the scan. It is having something check regularly, because a plugin that was safe last month may not be this month.

Reading the result properly

Severity is usually given as a CVSS score. Above 7 is worth treating as urgent, but read the description rather than the number — an "unauthenticated file upload" at 6.5 is far more dangerous in practice than an "authenticated admin XSS" at 8.

Unauthenticated in the title is the word that matters most. It means the attacker does not need to log in, which means it can be exploited at scale by bots. Those are the ones that get sites hacked in bulk.

Fixed in tells you the version to reach. If it says "no fix available", that is a different problem — see below.

What to do about it

If a fix exists: update today, not at the weekend. Back up first, update, then check your key pages. The whole thing takes fifteen minutes and closes the window.

If no fix exists yet: deactivate and delete the plugin until one ships. Deactivating alone is not enough for some flaws, because the code remains reachable on disk. If the plugin is essential to the site, look for an alternative — and if the developer has not responded to a disclosure, assume they will not.

If the plugin has been closed on wordpress.org: it is not coming back. Replace it. This has happened to several widely-used plugins over the past year.

Making it a habit rather than a panic

Realistically, nobody is going to check twenty plugins by hand every week. So either automate it, or have somebody do it.

Our care plans include vulnerability monitoring — your plugins checked continuously, and patched within days of a disclosure rather than at the next time anyone remembers. From $79 a month.

Or install the free plugin, which runs the same check weekly and emails you if something changes. That costs nothing and is a genuine improvement on checking never.