WordPress Plugin Vulnerabilities: How to Audit Your Plugins Before Attackers Do

Last spring, a small agency we know maintained forty-one WordPress sites for clients across retail, a dental practice, and two nonprofits. When they finally ran a proper inventory, they found that nine of those sites were running a contact form plugin with a known unauthenticated file upload flaw that had been public for more than four months. None of the sites had been hacked yet. The developers who built the plugin had shipped a fix, and the agency simply had never updated because nobody owned the job of checking. That gap, between a vulnerability being published and a site owner actually knowing about it, is where most WordPress compromises happen.

WordPress powers a large share of the public web, and plugins are the reason it is useful and the reason it is risky. The official plugin directory hosts tens of thousands of extensions, and a meaningful fraction of the vulnerabilities attackers exploit live not in WordPress core but in third-party code that a site owner installed years ago and forgot about. Automated scanners sweep the web for specific plugin versions with known flaws, so the window between disclosure and mass exploitation can be measured in days, sometimes hours.

This article is about the practical side of that problem. You will learn what a WordPress plugin vulnerability check actually involves, how to inventory and rank your plugins by risk, how to read a vulnerability advisory without a security background, how to verify that a plugin is safe to keep before you touch it, and what to do when you find something bad. Where it helps, I'll show the numbers and the workflow I use myself across the handful of sites I manage. The aim is an audit you can finish in an afternoon and repeat every month without it becoming a chore.

Key Takeaways

• Most WordPress compromises exploit outdated third-party plugins, not WordPress core, and the exploit often arrives within days of public disclosure.
• Start with a complete inventory: every active and inactive plugin, its version, its last update date, and its author. Inactive plugins still expose code if their files remain on disk.
• Rank plugins by risk using four factors: whether they handle user input or uploads, whether they are abandoned, how many users they have, and how long since their last release.
• Check vulnerability databases such as WPScan and the Patchstack database, and subscribe to advisories for the plugins you rely on most.
• Remove plugins you do not need instead of merely deactivating them. Deletion removes the attack surface entirely.
• Repeat the audit on a fixed schedule, and keep a written record so you can prove what you checked and when.

What Is a WordPress Plugin Vulnerability Check?

A WordPress plugin vulnerability check is a structured review of the plugins installed on a site to identify known security flaws, outdated code, and risky configurations before an attacker exploits them. It combines three activities: inventorying what is installed, matching each plugin against published vulnerability records, and assessing the plugins that have no published record but show warning signs of poor maintenance.

The check is different from a malware scan. A malware scanner looks for code that has already been injected into your files. A vulnerability check looks for the doors that are open, whether or not anyone has walked through them yet. You want both, but the vulnerability check is the one that prevents an incident rather than cleaning one up.

Vulnerability vs. malware vs. misconfiguration

• Vulnerability: A flaw in plugin code, such as SQL injection, cross-site scripting, or an unauthenticated file upload, that an attacker can use to do something the site owner did not intend.
• Malware: Malicious code already present on the site, often a backdoor or a spam injector.
• Misconfiguration: A setting that weakens security, such as directory listing enabled, debug mode left on, or a plugin that exposes an admin endpoint to the public.

A complete audit covers all three. This article concentrates on vulnerabilities, because they are the category most site owners underestimate.

Step 1: Build a Complete Plugin Inventory

You cannot audit what you have not listed. The most common mistake I see is an owner who checks the plugins shown on the Plugins screen and forgets the rest. Inactive plugins still have their PHP files on disk, and in many configurations a direct request to a plugin file can still execute code. Treat every folder in wp-content/plugins as in scope.

A worked example: 47 plugins across 12 sites

Say you manage twelve WordPress sites, and each has an average of four active plugins and three inactive ones. That is 84 plugin installations. If you audit only the active ones, you skip 36 of them, which is nearly half your exposure. In the agency case above, the team had 312 plugin installations across 41 sites, and a little under a third were inactive leftovers from old projects.

How to build the inventory

1. Log in to each site's WordPress admin and open Plugins. Note every plugin, its status (active or inactive), installed version, and whether an update is available.
2. If you manage many sites, export the list with WP-CLI rather than clicking through each one. Run wp plugin list --format=csv > plugins.csv from the site root, or wp plugin list --status=inactive to isolate the dormant ones.
3. Record the last-updated date for each plugin. The plugin directory page shows "Last updated," and that date is one of your strongest risk signals.
4. Record the plugin author or vendor and whether that vendor still publishes updates for other products.
5. Store the inventory in a spreadsheet with one row per plugin per site. Add columns for version, status, last-updated, and a blank column for risk rating, which you will fill in during Step 2.

Step 2: Rank Your Plugins by Risk

Once you have the list, you need to decide where to spend your time. Not every plugin deserves equal attention. A plugin that displays a copyright footer carries far less risk than one that processes form submissions, handles file uploads, or stores customer data.

The four-factor risk model

I score each plugin on four factors, each from 1 (low risk) to 3 (high risk), and add them together. A total of 10 or more goes to the top of the queue.

1. Attack surface: Does it accept user input, file uploads, or API requests from unauthenticated visitors? Forms, membership plugins, page builders with frontend editing, and e-commerce extensions score high.
2. Maintenance status: When was the last release? Anything untouched for more than 12 months scores high. Anything not updated in more than 24 months is effectively abandoned.
3. Popularity and scrutiny: Plugins with very few installs receive less community review, so they can hide flaws longer. Very popular plugins get more eyes but are also bigger targets.
4. Vendor trustworthiness: Does the author have a track record, a support channel, and a history of responding to security reports? An unknown author with no contact information scores high.

Worked scoring example

Consider three plugins on one site:

• A contact form plugin, last updated four months ago, 200,000 installs, established vendor. Attack surface 3, maintenance 2, popularity 1, vendor 1. Total: 7. Medium priority.
• A front-end file manager plugin, last updated 26 months ago, 900 installs, single developer, no support page. Attack surface 3, maintenance 3, popularity 3, vendor 3. Total: 12. Remove immediately.
• A decorative slider, last updated six weeks ago, 80,000 installs, reputable vendor. Attack surface 1, maintenance 1, popularity 1, vendor 1. Total: 4. Low priority.

The file manager is the one to act on today, even though it is not the most popular, because it combines an open input surface with abandonment.

Step 3: Check Plugins Against Vulnerability Databases

Ranking tells you where to look. Vulnerability databases tell you what is already known. The two most useful free resources for WordPress are WPScan's vulnerability database and the Patchstack database. Both index disclosed flaws by plugin name and version range, and both let you search without creating an account.

Comparison of common vulnerability resources

Resource	Cost	Coverage	Searchable by plugin and version	Alerts or API	Best for
WPScan Vulnerability Database	Free to browse, paid API tiers	Core, themes, plugins	Yes	API on paid plans	Manual lookups and reports
Patchstack Database	Free to browse	Core, themes, plugins	Yes	Alerts through the Patchstack platform	Quick checks and ongoing monitoring
WordPress.org plugin page (Security tab)	Free	Only plugins in the directory	Per plugin	Update notices in the admin	Confirming a fix is shipped
CVE / NVD search	Free	Broad, not WordPress-specific	Keyword search	RSS and API	Cross-referencing a named flaw
Wordfence Intelligence	Free and paid	Core, themes, plugins	Yes	Alerts and API	Teams already using Wordfence

How to run the lookup

1. Open the vulnerability database of your choice and search for the plugin's exact slug or name.
2. Find the entry matching your installed version. Pay attention to the "fixed in" version, not just the vulnerable range.
3. If your version falls inside the vulnerable range, the plugin is a priority. Update first, and if no fixed version exists, move to the removal steps later in this article.
4. Note the vulnerability type. Unauthenticated SQL injection and arbitrary file upload are critical. Stored cross-site scripting that requires an admin to click something is usually lower priority, though still worth fixing.
5. Record the CVE identifier in your spreadsheet so you can reference it when you report internally or to a client.

Step 4: Read an Advisory Without a Security Background

Advisories are written for security engineers, and they can be intimidating. You do not need to understand exploit mechanics to act on one. You need to extract four facts: what is affected, whether exploitation requires login, what the fix is, and whether exploitation is known to be happening.

A sample breakdown

Imagine an advisory reading: "The plugin's image import function fails to validate file types, allowing an unauthenticated attacker to upload arbitrary

Cover image: Innovate Maryland Emerging Technology Center by MDGovpics, licensed under BY 2.0 via Openverse.