Most WordPress site owners think about security when something breaks. A redirect shows up in search results, a hosting provider sends a suspension notice, or a client calls to say their contact form is spamming them with pharmaceutical ads. By then, the attacker has usually been inside for weeks. The uncomfortable truth is that the most common entry point is not WordPress core, which receives rapid security patches, but the plugins sitting on top of it. A typical WordPress site runs somewhere between 15 and 30 plugins, and each one is a separately maintained codebase with its own release cycle, its own developers, and its own mistakes. Public vulnerability databases tell the same story. Year after year, the majority of publicly catalogued WordPress vulnerabilities originate in third-party plugins rather than in core. Many of these flaws are not exotic. They are missing nonce checks, unvalidated file uploads, SQL queries built from raw user input, and privilege checks that quietly assume the requester is an administrator. Attackers do not need to discover anything new. They run automated scanners that match your plugin list against published advisories within hours of disclosure. This article is a practical audit guide. You will learn how to inventory what is actually running on your site, how to judge whether a plugin is risky before you install it, how to check for known vulnerabilities, how to spot signs of compromise, and how to build a routine so this does not become a one-time panic. I have run this process on client sites and on my own properties, and the steps below are the ones that consistently find real problems. Where a tool or product helps, I will say so, along with its tradeoffs.
Key Takeaways
- Most WordPress compromises start in a plugin, not in WordPress core. Your audit should begin with your plugin list.
- Inventory everything, including inactive plugins and themes. Deactivated code is still reachable on many sites.
- Check each plugin against vulnerability databases, its last update date, its active install count, and whether the developer responds to reports.
- Remove plugins you do not use. Fewer plugins means a smaller attack surface and fewer updates to track.
- Look for indicators of compromise: unknown admin users, modified core files, unexpected scheduled tasks, and outbound traffic you cannot explain.
- Audit on a schedule, not once. Set a monthly review and a same-day response rule for critical advisories.
What Is a WordPress Plugin Security Audit?
A WordPress plugin security audit is a structured review of every plugin installed on a site, aimed at answering three questions. Is the plugin still maintained? Does it have known vulnerabilities, and if so, are they patched? And does the site show any sign that a vulnerable plugin has already been exploited? A complete audit covers both the code you run and the evidence of what has happened to it.
People often confuse an audit with a scan. A scanner is one input into an audit. A proper audit combines automated checks with human judgment about whether a plugin belongs on your site at all.
The four layers of a plugin audit
- Inventory: What is installed, what is active, what version, and where it came from.
- Vulnerability status: Whether known CVEs or published advisories affect your versions.
- Maintenance health: Whether the developer is still shipping updates and responding to security reports.
- Compromise check: Whether there are signs the site has already been breached.
How Do You Build a Complete Plugin Inventory?
You cannot secure what you have not listed. Most site owners think they know their plugins, and most are wrong by a handful. The gap is usually inactive plugins, abandoned themes, and "must-use" plugins dropped into the mu-plugins folder by a previous developer.
Step-by-step inventory walkthrough
- Log in to the WordPress admin and open Plugins → Installed Plugins. Use the filter links to view All, Active, and Inactive plugins separately. Write down the count from each.
- Export the list. The admin table does not export natively, so either copy the rows into a spreadsheet or use WP-CLI. If you have shell access, run
wp plugin list --format=csv > plugins.csv. The output includes name, status, version, update availability, and version. - Check the
wp-content/mu-plugins/folder over SFTP. Must-use plugins load automatically and do not appear in the standard plugin screen. Anything in that folder runs on every request. - Check
wp-content/plugins/directly for folders that do not appear in the admin list. A folder with no matching entry in the admin is a red flag, sometimes a leftover from a removed plugin and sometimes a planted file. - List themes at Appearance → Themes and note any parent or child themes you no longer use. Inactive themes carry the same risk as inactive plugins.
- For each entry, record four things: the plugin slug, installed version, source (WordPress.org, a premium vendor, or a custom build), and the date of the last update.
A worked example
Consider a small business site I audited recently. The owner said they ran "about ten plugins." The inventory told a different story. There were 14 plugins installed, 6 of them inactive. Two of the inactive plugins were form builders the team had replaced a year earlier. There was also a folder in wp-content/plugins/ named after a theme that was no longer on the site. Three plugins had not been updated in more than 18 months.
Removing the six inactive plugins and the orphaned folder took about twenty minutes. That single step cut the list of code that needed monitoring from 14 items to 8. The remaining work was far more manageable.
How Do You Check Plugins for Known Vulnerabilities?
Once you have a list, the next question is whether any of those plugin versions have publicly documented flaws. The core databases to check are the WPScan Vulnerability Database, the National Vulnerability Database (NVD) for CVE entries, and the advisories published by the plugin developer and the WordPress.org plugin repository. Automated tools can query these for you.
Manual check, one plugin at a time
- Open the plugin's page on WordPress.org or the vendor site and note the version you have installed.
- Search the WPScan database for the plugin slug. Each entry lists the affected version range, the fixed version, and the vulnerability type.
- Search the NVD or CVE records for the plugin name plus "WordPress." This catches advisories that WPScan may have missed or categorized differently.
- Compare your installed version against the "fixed in" version. If you are below it, the plugin is vulnerable.
- Record the result in your spreadsheet with a severity rating: critical (remote code execution, unauthenticated access to admin functions), high (SQL injection, stored XSS), medium (authenticated issues requiring a low-privilege account), or low.
Automating the check
Doing this by hand works for ten plugins. It stops working at fifty, especially across several sites. A WPScan API key lets you query the database programmatically, and many hosting dashboards and security plugins now show vulnerability warnings inline. If you manage a portfolio of sites, a central dashboard that pulls plugin inventories from each install is worth the setup time.
If you want a turnkey option, SiteGuard Pro is designed to surface outdated and vulnerable components alongside its firewall and file-integrity features, so you are not juggling separate tabs for each check. For a lighter-weight approach focused on blocking abusive traffic while you patch, WordPress IP Blocker Pro can cut off the automated scanners that hit known-vulnerable paths before you have finished your review. Neither replaces patching, but both buy time.
How Do You Evaluate a Plugin Before You Install It?
Auditing existing plugins is only half the job. The other half is deciding whether a new plugin deserves a place on your site at all. Most vulnerable plugins were abandoned or were built by developers without security training. A few signals predict this well.
Red flags and green flags
- Last updated more than 12 months ago: Red flag, unless the plugin is trivially simple and has no external input.
- "Tested up to" version lags current WordPress by more than two major releases: Red flag, suggests the developer has stopped paying attention.
- Few active installations but a high rating from a small number of reviews: Treat with suspicion. Review counts can be gamed.
- Support forum threads with security reports and no developer response: Strong red flag.
- A changelog that says "security fix" with no detail: Neutral to positive, as long as the next release follows through.
- Clear vendor identity, a published security policy, and a responsive contact address: Green flag.
Free versus premium versus custom
Premium plugins are not automatically safer than free ones, though they often receive more consistent maintenance because the vendor has revenue riding on it. Custom or "nulled" plugins, where a licensed premium plugin has been cracked and redistributed, are the most dangerous category. Nulled plugins frequently ship with injected backdoors, and this is one of the most common ways sites are compromised in practice. Treat any pirated plugin as already breached until proven otherwise.
How Does a Plugin Source Affect Your Risk?
Where a plugin comes from changes your exposure, your update path, and your response options. The comparison below reflects typical patterns, not guarantees.
| Source | Update Reliability | Vulnerability Disclosure | Integrity Risk | Support Accountability | Typical Use Case |
|---|---|---|---|---|---|
| WordPress.org repository | Varies widely by maintainer | Public, indexed by WPScan | Low, code is reviewed on submission | Community forums, variable | Most general-purpose needs |
| Premium vendor (direct) | Usually consistent | Vendor-controlled, sometimes delayed | Low if bought from the vendor | Paid support and SLAs | Business-critical functions |
| Marketplace reseller | Depends on vendor and reseller | Can lag the vendor | Low to medium, verify the source | Split between reseller and vendor | Budget-conscious buyers who verify provenance |
| Custom-built by an agency | Only as good as the agency | Rarely published | Medium, depends on code review | Contractual only | Unique requirements |
| Nulled or cracked |
