Every WordPress site is one bad plugin away from disaster. The average WordPress install runs 20 to 30 plugins, and each one is code you did not write, running with near-total access to your database, your files, and your visitors' data. When one of those plugins ships a vulnerability that attackers exploit before a patch exists, that is a zero-day, and it will not announce itself in your dashboard.
Here is a number that should keep you up at night: according to Patchstack's annual vulnerability data, over 90% of new WordPress security issues originate in plugins, not in core WordPress itself. And a meaningful share of those get weaponized within 24 to 48 hours of public disclosure. If you install a plugin the day before its flaw goes public, you inherit the risk without any warning.
The good news is that you can dramatically lower your exposure with a repeatable audit you run before you ever click Install. In this guide I will walk you through exactly how to audit WordPress plugin security like someone who has cleaned up the aftermath more than once. We will cover the signals that predict trouble, a scoring rubric you can copy, a worked example, and the tools worth keeping in your kit.
Key Takeaways
- Audit before install, not after. Zero-day exploitation windows are often measured in hours, so your prevention has to happen earlier than your patching.
- Vendor track record beats star ratings. A plugin's patch history and disclosure response tell you more than 5-star reviews ever will.
- Read the code, or read someone who read the code. Even a 15-minute skim of the source reveals dangerous patterns like unsanitized inputs and remote calls.
- Fewer plugins, better plugins. Each plugin is attack surface; consolidating to well-maintained tools lowers your total risk.
- Layer defenses. A firewall, IP-level blocking, and file integrity monitoring buy you time even when a zero-day slips through.
What "Zero-Day Risk" Actually Means for a Plugin
A zero-day is a vulnerability that is exploited before the developer has released a fix, meaning defenders have had "zero days" to prepare. For a WordPress plugin, that usually looks like one of a handful of recurring flaws:
- SQL injection — unsanitized input reaches a database query, letting attackers read or rewrite your data.
- Cross-site scripting (XSS) — the plugin echoes user input into a page without escaping it, so attackers inject scripts into your admin or visitors' browsers.
- Broken access control — an endpoint that should require admin rights checks nothing, so any logged-in user (or nobody) can trigger it.
- Arbitrary file upload — the classic path to a web shell and full site takeover.
- Unauthenticated remote code execution — the worst case, where an attacker runs code on your server without logging in.
You cannot predict the exact bug that will surface next quarter. What you can do is estimate the probability that a given plugin will ship one, and how quickly the author will respond when it happens. That estimate is the entire point of a pre-install audit.
The Pre-Install Audit Checklist
Run this in order. It takes 15 to 30 minutes per plugin, which feels like a lot until you compare it to the 40 hours you will spend recovering from a compromise.
1. Verify the vendor before the product
Who actually maintains this plugin? A named company with a support address and a track record is a very different risk profile from an anonymous handle that appeared eight months ago. This is the same discipline I covered in depth on how to audit software vendor ownership before you buy, and it applies just as hard to plugins.
- Find the developer's real name or company. Cross-check against their website and WHOIS.
- Look for a security contact or a
SECURITY.md. Vendors who plan for disclosure handle zero-days faster. - Check whether they publish a changelog with dated security fixes.
2. Read the maintenance signals
On the WordPress.org plugin page, look at four fields:
- Last updated — anything older than 6 months is a warning; older than 12 is a red flag.
- Tested up to — should match a recent WordPress version.
- Active installations — more eyes usually means faster discovery, but also a bigger target.
- Support threads resolved — a graveyard of unanswered threads predicts a slow patch response.
3. Check public vulnerability databases
Before installing, search the plugin's slug in the free vulnerability feeds. This tells you its history, and history rhymes.
- Search the plugin name in the WPScan vulnerability database.
- Cross-check Patchstack and the CVE database.
- For each past vulnerability, note the time between disclosure and the patched release. A pattern of same-week patches is a green light. A pattern of "never fixed, plugin closed" is a hard no.
4. Skim the source code
You do not need to be a security engineer to spot the obvious. Download the plugin zip, unpack it, and grep for dangerous patterns:
eval(,base64_decode(,gzinflate(— obfuscation that legitimate plugins rarely need.$_GET,$_POST,$_REQUESTused directly in$wpdb->query()withoutprepare().file_get_contents(orcurlcalls to external domains you do not recognize.- Missing
current_user_can()andcheck_admin_referer()around actions that change data.
If you find phone-home code beaconing to an unknown server, treat it the way you would treat a shady browser add-on. The same instinct I described in how to vet browser extensions before granting AI panel access transfers directly: unexplained network calls are a trust failure until proven otherwise.
5. Test in an isolated staging environment
Never install a new plugin directly on production. Spin up a staging clone, install the plugin, and watch what it does:
- Monitor outbound connections with your host's logs or a tool like
tcpdump. - Check whether it added scheduled tasks, admin users, or new database tables.
- Run a file integrity scan before and after to see exactly what changed.
A Scoring Rubric You Can Copy
Vague gut checks do not scale across a team. Turn the audit into a score out of 100, and set a threshold below which you simply do not install. Here is the rubric I use.
| Signal | What earns full points | Weight |
|---|---|---|
| Vendor identity | Named company, security contact, public disclosure policy | 20 |
| Patch history | Past vulnerabilities fixed within 7 days | 25 |
| Maintenance recency | Updated within 3 months, tested on current WP | 15 |
| Code hygiene | No obfuscation, sanitized inputs, capability checks | 25 |
| Footprint | Minimal permissions, no unexplained external calls | 15 |
My rule: install freely at 80+, install with monitoring at 60 to 79, and reject below 60. It is not scientific to the decimal, but it forces a consistent, defensible decision every time.
A Worked Example: Auditing Two Contact Form Plugins
Say you need a contact form and you have narrowed it to two candidates. Let us call them Plugin A (50,000 installs, big brand) and Plugin B (2,000 installs, solo developer). The star ratings are nearly identical: 4.7 versus 4.8. Ratings alone would push you toward B. The audit tells a different story.
Vendor identity. Plugin A is maintained by a company with a security page and a HackerOne link: full 20 points. Plugin B lists only a display name and a Gmail address: 8 points.
Patch history. Plugin A has three past CVEs, all patched within 5 days: 25 points. Plugin B has one CVE from 14 months ago that was never patched; the fix note says "will address in next major": 5 points.
Maintenance. Plugin A updated last week: 15 points. Plugin B last updated 11 months ago: 4 points.
Code hygiene. Plugin A's forms use nonces and sanitize_text_field() throughout: 22 points. Plugin B pipes $_POST['email'] straight into a database insert: 6 points.
Footprint. Plugin A calls only its own license server: 13 points. Plugin B beacons to an ad network on every page load: 4 points.
Totals: Plugin A scores 95. Plugin B scores 27. The higher-rated plugin is the one that would likely get you compromised. This is exactly why I never trust star ratings as a security signal, and why the same rigor applies whether you are vetting a plugin or, as I wrote elsewhere, vetting vibe-coded apps before you buy or ship them.
Free Scanners vs Managed Protection vs Manual Review
No single method covers everything. Here is how the three common approaches stack up.
| Criteria | Free scanners | Managed protection | Manual code review |
|---|---|---|---|
| Catches known CVEs | Yes | Yes | Only if you know them |
| Catches unknown zero-days | Rarely | Partially (virtual patching) | Sometimes |
| Time cost per plugin | 2 minutes | Near zero | 15 to 30 minutes |
