Check WordPress Plugins for Known Flaws

To check WordPress plugins for known flaws, list every plugin and theme with its exact version, search each one in a public vulnerability database, and compare your version to the fixed-in version in the report.

This guide is for owners of small WordPress sites who are not security experts. You will get a five-step routine you can finish in under an hour, a table of trusted databases, a plain-English way to read a report, and a closing table that tells you what to fix today and what can wait.

A quick definition first. A vulnerability is a mistake in code that an attacker can abuse. A CVE is a public ID for one, written like CVE-YYYY-NNNNN, so everyone can talk about the same flaw.

Why plugins and themes are the place to look

WordPress core has a dedicated team behind it. Your plugins and themes come from thousands of different authors with very different habits. Some are well maintained. Some are left alone for years.

That is why a published flaw usually lives in an add-on, not in WordPress itself. The good news is that most flaws are fixed in a newer version, so checking is mostly a matter of knowing which version you run.

Step 1: List every plugin and theme with its version

You need an exact inventory. Include inactive plugins too. Their files still sit on your server.

From the dashboard:

1. Go to Plugins > Installed Plugins and note each name and version.
2. Go to Appearance > Themes and do the same.
3. For a copy you can paste into a document, open Tools > Site Health > Info, then expand Active Plugins and Inactive Plugins.

From the command line, if you or your host can run WP-CLI (the official WordPress command-line tool):

wp plugin list --fields=name,status,version,update_version --format=csv
wp theme list --fields=name,status,version,update_version --format=csv

The name column is the plugin's slug, the short folder name inside wp-content/plugins. Databases index by slug, so keep it handy. A non-empty update_version means a newer release exists.

Step 2: Look each one up in a public vulnerability database

A WordPress plugin vulnerability database is a searchable list of published flaws, with the affected versions and the fixed version. Several are free to search.

Here is how to use them well:

• Search by slug, not by the pretty display name. Similar plugins often share words.
• Check at least two sources. Each one finds and writes up different flaws, so coverage differs.
• Also open the plugin's page on WordPress.org (https://wordpress.org/plugins/your-slug/). Look at Last updated, Tested up to, and the Changelog under Details. A closed plugin shows a clear notice.
• For paid plugins and themes, which are not on WordPress.org, read the vendor's own changelog and security notices.

Can a tool do this for me?

Yes. A scanner plugin, such as Wordfence or Patchstack, reads your plugin inventory and matches it against the same databases, so you can leave it running. Just know what it does: it mostly compares version numbers to known entries. It cannot find a flaw nobody has reported yet. WPScan is mainly a database and API, which is why it appears in the table above and not as a plugin we recommend here.

Step 3: Read the report

A good entry answers a handful of questions. Here is a made-up example so you can see the shape:

Example Gallery (fictional)
Type: Arbitrary file upload
Affected versions: 4.2.1 and below
Fixed in: 4.2.2
Who can exploit: Unauthenticated (anyone)
Severity: Critical (CVSS 9.8)

Go through the fields in this order:

• Affected versions. If you run 4.2.1, you are exposed. If you run 4.3.0, this entry is not about you.
• Fixed in. This is your target version. If it is blank, no patch exists yet.
• Who can exploit it. Unauthenticated means a stranger with no account. Subscriber means someone who can register or log in. Admin only usually means lower risk, because the attacker needs admin access first. The exception: an attacker can sometimes trick a logged-in admin into clicking a link (called CSRF, cross-site request forgery). A site with several admins or shared logins is also more exposed.
• Type. File upload, SQL injection (tricking the database), and privilege escalation (a normal user becoming admin) are usually the serious ones. Cross-site scripting (XSS, injecting script into your pages) varies. Check who can trigger it.
• Severity score. The CVSS score runs from 0 to 10. NVD defines the ranges as Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0. Treat it as a guide, not a verdict.
• Exploited in the wild. If a source says attackers are using the flaw, or CISA lists it, move it to the top of your list regardless of the score.

Step 4: Decide whether to update, replace or remove

Work through each flagged plugin with this order of questions.

1. Is a fixed version available? Then update. This is the usual answer.
2. No fix, and the flaw is serious? Deactivate the plugin now, then replace it or remove it.
3. Has the author gone quiet? WordPress.org itself warns when a plugin has not been updated in a long time. A plugin with no updates, no replies in support, and open security reports is a poor bet. Plan a swap.
4. Do you even use it? Most sites carry a few plugins they forgot about. Remove those.

Before any update, take a backup. If you have shell access:

wp db export ~/backup-$(date +%F).sql
wp plugin update example-gallery

Warning: never save a database dump inside your web root (the folder your site is served from, often public_html). Anyone who guesses the filename can download it, and it holds your site's data. Save it in a folder above the web root, as the ~/ path above does, and delete old dumps when you are done.

Otherwise run a backup with your host's backup tool or a backup plugin first. When it finishes, go to Plugins > Installed Plugins and click Update now. For a busy shop or membership site, try the update on a staging copy first, then load the main pages and test checkout or login.

When removing, delete it. Do not just deactivate. The files stay on your server, and a vulnerable file can sometimes be reached directly by URL even when the plugin is switched off. Back up first. Deleting a plugin can also delete the data it stored, such as form entries, orders and settings.

wp plugin deactivate example-gallery
wp plugin delete example-gallery

Or use Plugins > Installed Plugins > Deactivate > Delete.

If you were exposed to an unpatched, serious flaw for some time, check for signs that someone got in. Our website hacked guide walks through what to look for.

Step 5: Make it a routine

A one-off check goes stale fast, since new flaws are published all the time. Keep it light:

• Put a monthly 30-minute slot in your calendar to repeat Steps 1 to 3.
• Turn on auto-updates for plugins you trust under Plugins > Installed Plugins > Enable auto-updates. WordPress has supported this since version 5.5.
• Keep your plugin list short. Every plugin you remove is one less thing to track.
• Set up email alerts from a scanner plugin. For weekly outside checks that email you when something changes, see the Relay plan on pricing.

What databases cannot tell you

Databases only know about flaws someone found and published. They say nothing about a brand-new bug, custom code from a developer, weak admin passwords, or a risky server setting.

They also depend on matching names and versions, which can miss a renamed or bundled library. This is the gap between a scan and a person reading your site. Our guide on manual vs automated penetration testing explains the difference in plain terms.

Act the same day, or let it wait?

Key takeaways

• Build a full list of plugins and themes with exact versions, including inactive ones.
• Look each slug up in at least two databases, then compare your version to the fixed-in version.
• Read who can exploit it first. Unauthenticated, exploited-in-the-wild flaws come before everything else.
• Update after a backup, and delete plugins you do not use or that have no fix. Do not leave them deactivated.
• Repeat monthly, and remember a database check only covers flaws that are already public.

A human look is the honest next step

A database check tells you about known problems in known plugins. It cannot judge your whole site. If you want a person to go further, the Bug Circuit Circuit audit is $49 one time: a security engineer manually reviews your site and sends a written report with severity, evidence and exact fixes. It is a focused small-site audit, not an enterprise pentest or a compliance certificate. See pricing for details, or start with the free website security check.