How to Check If Your WordPress Site Is Affected by a Plugin Vulnerability

A CVE disclosure lands in your inbox, or you see a headline about a popular WordPress plugin being vulnerable. The immediate question is always the same: am I running that plugin, and is my version affected?

This guide walks through the exact steps to answer that question — using the same vulnerability databases security professionals use.

What a Plugin Vulnerability Actually Is

A WordPress plugin vulnerability is a security flaw in a plugin's code that an attacker can exploit to take an unauthorized action on your site. Common types include:

Cross-Site Scripting (XSS) — an attacker injects malicious scripts that run in visitors' browsers
SQL Injection — malicious input manipulates your database queries, potentially exposing or deleting data
Broken Access Control — a user with lower privileges (or no account at all) can perform actions they shouldn't be able to, such as uploading files or accessing protected content
Cross-Site Request Forgery (CSRF) — a victim's browser is tricked into making requests to your site on behalf of an attacker

Each of these has a different risk profile. A stored XSS flaw in a publicly accessible form is more immediately dangerous than an authenticated SQL injection that requires administrator-level login to trigger. The CVSS score (explained below) helps communicate that difference in a standardized way.

Step 1: Find Your Installed Plugin Versions

Before you can check a vulnerability database, you need two pieces of information: the plugin slug (the unique identifier WordPress uses for the plugin) and your currently installed version.

Both are visible in your WordPress admin panel:

Log in to your WordPress admin (typically yourdomain.com/wp-admin)
Go to Plugins → Installed Plugins
Each row shows the plugin name, a brief description, the installed version number, and the author
The version number is displayed directly below the plugin name in grey text

Write down or copy the version number for the specific plugin you want to check. You'll need the exact version — "5.3" and "5.3.1" are different versions and may have different vulnerability profiles.

The plugin slug — used in vulnerability database searches — is the directory name WordPress uses for the plugin. If you see the plugin listed on WordPress.org, the slug is the last segment of its URL: for example, wordpress.org/plugins/contact-form-7 has the slug contact-form-7.

Step 2: Check the Vulnerability Databases

Two databases cover the overwhelming majority of disclosed WordPress plugin vulnerabilities. Use both — their coverage is not always identical.

Patchstack Database

patchstack.com/database is a searchable vulnerability database focused specifically on WordPress. As of May 2026 it lists over 47,000 total vulnerabilities. It is free to search.

To use it:

Go to patchstack.com/database
Type the plugin name or slug into the search field and click Search
Each result shows the affected version range, the vulnerability type, the CVSS score, and whether an official patch exists

The "No official patch" filter on the Patchstack database — which showed 12,921 entries as of May 2026 — is particularly useful: it surfaces vulnerabilities where no fixed version has been released yet. If your plugin appears there with no patch, updating to the latest version will not resolve the issue.

WPScan Vulnerability Database

wpscan.com/plugins maintains a dedicated list of WordPress plugin vulnerabilities organized alphabetically by plugin slug. It is free to browse.

To use it:

Go to wpscan.com/plugins
Use the alphabetical navigation to browse to the first letter of your plugin slug
Find your plugin in the list and review the disclosed vulnerabilities alongside their publication dates

WPScan also offers a paid API that can automate this check across all your installed plugins — useful if you manage multiple sites.

National Vulnerability Database (NVD)

The National Vulnerability Database (nvd.nist.gov), maintained by the US National Institute of Standards and Technology, is the authoritative registry for CVE IDs. Every CVE that gets a formal ID ends up here.

It is not WordPress-specific, which makes it less convenient to browse than Patchstack or WPScan, but it is useful for looking up a specific CVE ID if you already have one (for example, from a security advisory). Search by the CVE ID directly: CVE-YYYY-NNNNN.

Step 3: Understand What You're Reading

Vulnerability disclosures use two key pieces of information to communicate severity:

The CVE ID

A CVE (Common Vulnerabilities and Exposures) ID is a unique identifier assigned to a specific vulnerability. The format is CVE-[year]-[number], for example CVE-2024-12345. The year is when the CVE was reserved, not necessarily when the vulnerability was discovered or disclosed. When a security advisory references a CVE ID, you can look it up directly in the NVD for the authoritative description.

The CVSS Score

The CVSS (Common Vulnerability Scoring System) score is a number from 0.0 to 10.0 that communicates severity. The official ranges are:

0.0: None
0.1–3.9: Low
4.0–6.9: Medium
7.0–8.9: High
9.0–10.0: Critical

The CVSS score alone does not tell you the full story. A 9.8 Critical vulnerability that requires no authentication to exploit on a public-facing form is an immediate emergency. A 7.5 High vulnerability that can only be triggered by an authenticated user with Administrator-level access is still serious, but the actual attack surface is much smaller. Always read the description alongside the score.

Affected Version Range

Vulnerability listings specify which versions are affected, typically in one of two ways:

"All versions up to and including X.X.X" — every version from the initial release through the specified version is vulnerable; the fix is in the next release
"Versions X.X.X through Y.Y.Y" — a vulnerability introduced in a specific version, patched in a later one

Compare this against your installed version number from Step 1. If your version falls within the affected range, you are exposed.

Step 4: What to Do If You Are Affected

If a patch exists: update immediately

Go to Dashboard → Updates in WordPress admin. If an update is available for the affected plugin, it will be listed there. Click Update.

Before updating on a production site, if you have a staging environment, apply the update there first and verify nothing breaks. If you do not have staging, take a full backup first. Your hosting provider's control panel typically has a backup tool, or you can use a backup plugin.

After updating, return to the vulnerability database and confirm your new version number is no longer in the affected range.

If no patch exists: deactivate the plugin

If the vulnerability database shows "No official patch" and your version is affected, updating the plugin will not resolve the issue. The options are:

Deactivate the plugin until a patch is released. Go to Plugins → Installed Plugins, find the plugin, and click Deactivate. This removes the functionality the plugin provides, but it also removes the attack surface.
Find an alternative plugin that provides the same functionality and does not carry the open vulnerability.
Monitor the plugin's changelog on its WordPress.org page for a security release. The Changelog tab on each plugin's WordPress.org listing records every version update.

Do not leave a vulnerable plugin active because you depend on its functionality. An actively exploited vulnerability on a site with known traffic will be found.

If your version is not in the affected range

You are not exposed to that specific vulnerability. No action is required beyond noting the disclosure in case future research expands the affected range.

Step 5: How to Stay Informed Going Forward

Checking databases manually after every disclosure is not a sustainable workflow if you manage more than one or two sites. A few options that require no paid tools:

Patchstack free tier: Patchstack offers a free plan that monitors a limited number of sites and sends email alerts when a vulnerability is disclosed for a plugin you have installed. The free tier has limitations but is useful for small site counts.
WPScan email alerts: WPScan's API has a free tier that can be configured to send notifications for specific plugins.
WordPress.org plugin pages: Each plugin's page on WordPress.org has a "Support" forum and a "Changelog" tab. Significant security releases are almost always noted in the changelog.
Vortex Media's monthly security roundup: We publish a monthly summary of the most significant WordPress plugin CVEs disclosures at our blog. No account required.

The Managed Hosting Alternative

The process above is accurate and works. It is also manual — and it requires you to repeat it every time a disclosure affects a plugin on your site.

On Vortex Media's managed hosting plans, plugin vulnerability monitoring is handled automatically. When a vulnerability is disclosed for a plugin installed on a site on our infrastructure, we are notified and push the update — or contact you if a deactivation decision is needed — without requiring you to run through the steps above yourself.

If your site is running a business that depends on uptime and data integrity, the time cost of ongoing manual monitoring is real. Our hosting plans start at $9.99/month.