Check WordPress Plugins and Themes for Known Vulnerabilities

WooCommerce Wholesale Lead Capture's advisory reads: affected versions <= 2.0.3.1, fixed in 2.0.3.2. That single line is the entire gap between a site that's still open to an unauthenticated file upload and one that isn't. We covered the live attacks against that exact plugin: Wordfence blocked over 100,000 exploit attempts against sites still running the affected versions.

Knowing what's installed isn't the same as knowing what's vulnerable. This guide walks through both: how to get an accurate list of your plugins and themes with their exact versions, how to read what an advisory actually says, where to check that list against real disclosure data, and how to decide what to fix first when several things need attention at once.

Step 1: Get an accurate list of what's installed

You can't check anything against a vulnerability database without knowing the exact version running right now, not the version you remember installing.

From the dashboard: go to Plugins > Installed Plugins. Each row shows the plugin name and, in small text beneath it, the currently installed version. Appearance > Themes shows the same for themes, though you'll need to open each theme's details to see its version number.

From WP-CLI, one command gives you the whole plugin list with the fields that matter for a vulnerability check:

wp plugin list --fields=name,status,version,update_version

status tells you if a plugin is active or merely installed. Don't skip inactive ones: a vulnerable file can sometimes be requested directly, and an inactive plugin is one click away from being active again. version is what you're actually running. update_version shows the newer release WordPress has already detected, when one exists, which matters for the next section. Run the theme equivalent too:

wp theme list --fields=name,status,version,update_version

If you manage more than one site, script this across all of them and save the output. A spreadsheet of plugin-slug-plus-version, refreshed weekly, is the input every other step in this guide needs.

Step 2: Read an advisory correctly

Every vulnerability advisory states two things that matter, and mixing them up is the single most common mistake in checking your own exposure.

If your installed version is 2.0.3.1 or lower, you're exposed, full stop. If you're on 2.0.3.2 or higher, that specific CVE is closed. It sounds obvious written out like that, but two details trip people up in practice.

First, "affected versions" sometimes has a lower bound too, like ">= 1.5.0, <= 2.0.3.1", when the vulnerable code was only introduced partway through the plugin's life. Read the full range, not just the ceiling.

Second, a version number passing the fixed-in threshold doesn't guarantee the whole problem is gone. WWLC's own changelog lists a security fix for the upload handler in 2.0.3.1, yet the advisories still count 2.0.3.1 as affected, the complete fix arrived in 2.0.3.2, and two later releases added more hardening in the same code paths. Sitting on exactly the minimum patched version, and never updating again, is a bet that the vendor got it completely right on the first try.

Watch for one more phrase: "no fixed version listed." That means the developer hasn't shipped a patch at all, whether because the plugin is abandoned, was pulled from wordpress.org, or the report is too new. Every version of that plugin is still open, and updating won't help until, or unless, a fix ships.

Step 3: Check your list against the actual databases

The dashboard doesn't check this for you (more on that below), so you need to look it up somewhere that tracks disclosed WordPress vulnerabilities by plugin and version.

Wordfence and Patchstack are the two to check first for anything WordPress-specific, since they run the researcher programs that produce most of these disclosures in the first place. NVD carries the official CVE record but isn't WordPress-focused, so its plugin coverage often lags behind the specialist feeds. Search each by the plugin's slug (the part of its URL on wordpress.org, or the folder name under wp-content/plugins/), not just its display name, since display names change and search engines don't always match on them well.

Step 4: Understand why "update available" isn't a vulnerability check

The dashboard's "update available" badge tells you a newer version exists. It does not tell you whether the version you're running has a disclosed, exploitable flaw, and it stays silent in exactly the cases that matter most.

A premium plugin with an expired license often stops receiving update notices, including security ones, even though the vulnerable code is sitting there unpatched. A plugin that's been closed on wordpress.org for a policy or security reason can vanish from update checks entirely while every site still running it stays exposed. And a plugin with no fix released yet simply has nothing to show an "update available" badge for, because there's no newer version to point at. We go deeper on each in separate guides: expired premium licences and abandoned and closed plugins.

Even a clean "up to date" badge only means you're on the newest release, not that the newest release is free of known issues. Some fixes land quietly with no advisory at all: our earlier look at rising disclosure volume covers a case where a plugin's paid editions were patched with no public advisory, so a scanner checking only public disclosure data would have shown those sites as clean while they were still running the vulnerable code.

That's why step 3 has to happen on its own, deliberately, rather than assumed from the dashboard.

Step 5: Prioritize when more than one thing needs fixing

Most site audits turn up several outdated or flagged plugins at once. Fixing them in the wrong order leaves the most dangerous one open the longest, so use this ranking instead of just working top to bottom on a list.

1. Unauthenticated and actively exploited, first. A flaw that needs no login and is already being attacked in the wild is the one costing sites real damage right now. Patchstack's own research put the median time from disclosure to active exploitation at around 5 hours in 2025, so "I'll get to it this week" is a real risk window, not a formality.
2. Install count and exposure, second. A plugin running on every page of a busy site, or exposing a public-facing form or upload feature, has a bigger blast radius than one buried in an admin-only settings screen nobody uses.
3. Severity score, last. A CVSS number is a useful tiebreaker between two otherwise-similar issues, but a moderate-scored bug already under active attack beats a critical-scored one that's purely theoretical. Score alone shouldn't decide the order.

A simple weekly routine

You don't need daily monitoring to stay ahead of this. A short routine run once a week, on the same day each time, covers the gap.

• Run wp plugin list --fields=name,status,version,update_version and the theme equivalent across every site you manage. Save the output.
• For anything with a pending update, check whether the changelog or release notes call out a security fix specifically, not just new features.
• For plugins with no pending update badge at all, especially premium ones, spot-check the plugin's slug against Wordfence Intelligence and Patchstack directly, since a silent dashboard doesn't mean a clean plugin.
• Cross-check the list against our vulnerability database, or run a scan, so you're not relying on memory of which advisories you've already read.
• Apply fixes in the priority order from step 5, and note what you checked and when, so the next weekly pass picks up where this one left off.

This isn't a substitute for the rest of your security posture. Our WordPress security checklist covers the baseline hardening steps beyond plugin versions, and if you're already suspicious that something's gotten in, start with the signs a site has been hacked instead.

One more thing worth checking while you're at it: where the plugin actually came from. A nulled or pirated copy of a plugin can carry a backdoor baked in on day one, version number and vulnerability database entirely beside the point.

Run a scan on your site to check your installed plugin versions against our vulnerability database.

Related guides

• Expired premium plugin licenses and missed security updates
• How to spot abandoned and closed plugins
• How to verify a plugin update is genuine
• WordPress plugins to patch this week

References

• Wordfence: Attackers Actively Exploiting Critical Vulnerability in WooCommerce Wholesale Lead Capture Plugin
• Patchstack: WordPress Woocommerce Wholesale Lead Capture Plugin <= 2.0.3.1 - Arbitrary File Upload (CVE-2026-27540)
• Wordfence Intelligence: WordPress Vulnerability Database
• Wordfence: Open-Source Projects Use the Wordfence Vulnerability Data Feed API and You Can Too
• Patchstack Vulnerability Database
• WPScan WordPress Security Scanner
• NVD Developers: API Documentation
• WP-CLI: wp plugin list
• WP-CLI: wp theme list
• Patchstack State of WordPress Security 2026