WordPress plugin vulnerability risk score: a 217-plugin security audit

This report started with an incident response. February 2026: an established WordPress merchant on managed hosting detected suspicious admin-user creation in their database audit log. The pattern matched a known exploit on a popular page-builder plugin disclosed via Patchstack three weeks earlier — for which a patch was available, but had not been auto-applied because the merchant had disabled auto-updates after a previous plugin update broke their checkout. The exploit window between disclosure and patch had been used to install a backdoor, dormant for 19 days, before the auto-generated admin user was finally created.

The cleanup took 6 days, including a full database restore from the last verified clean backup, plugin re-audit, and a full set of credential rotations. The merchant's engineering bill for the incident eclipsed a year of plugin maintenance work. We came out of that engagement asking the obvious question: which plugins are most likely to be the next vector?

The 217-plugin audit below is the answer. WordPress runs roughly 43% of the public web. Most WordPress incidents are not zero-days against core — they are unpatched vulnerabilities in third-party plugins. The question is which plugins, in which categories, present real risk in 2026 and which are mostly fine.

We sampled the 217 most-installed plugins across 14 categories on WordPress.org and scored each on three metrics derived from WPScan, Patchstack, and WordPress.org metadata: Plugin Vulnerability Risk (PVR), Maintainer Fragility Index (MFI), and Replacement Availability Index (RAI).

Methodology

Plugin selection: top 217 by active install count on WordPress.org, distributed across 14 functional categories. Vulnerability data: WPScan public database for CVE counts and CVSS scores, Patchstack feeds for recent disclosures (last 24 months). Maintainer health: WordPress.org plugin metadata (last update, support response rate, contributor count). Cross-checked manually for borderline cases.

Finding 1: Four categories carry most of the risk

Page builders (PVR 78), WooCommerce extensions (72), membership / LMS (75), and marketing / popups (70) sit at the top of the risk table. The mechanism is the same in every case: large attack surface (forms, file uploads, payments, user roles), big install base, and uneven maintainer quality across the long tail of the category.

Finding 2: Install count amplifies, doesn't protect

Conventional wisdom says "use popular plugins, they get audited". The data partly supports that — at the very top of categories (5M+ installs), things tend to be well-maintained. But install volume is not protection by itself: the popular page builder at 6M installs sits at PVR 82, higher than the popular forms plugin at 5M installs (PVR 65). The only reliable signal is recent update activity and a clean Patchstack record.

Finding 3: Abandonment correlates with category complexity

Marketing / popup plugins lead the abandonment table at 41%. WooCommerce extensions follow at 32%. The mechanism is depressing but predictable: a developer ships a point-solution plugin to scratch their own itch, gets a few thousand installs, then gets a real job and stops maintaining. The plugin remains installed on tens of thousands of sites, accumulating vulnerabilities.

How we score plugin risk

1. Plugin Vulnerability Risk (PVR)

PVR = (Recent CVE severity sum × log(installs)) ÷ days-since-update factor

0-100. PVR 50+ is "requires active maintenance discipline"; 70+ is "evaluate replacement"; 80+ is "remove unless mission-critical".

2. Maintainer Fragility Index (MFI)

MFI = 100 − (active contributors × support response rate × update frequency)

How likely the plugin is to fall into abandonment. MFI 60+ on a category-leading plugin is a leading indicator of risk.

3. Replacement Availability Index (RAI)

RAI = (# viable alternatives ÷ functional gap) × maintainer-health avg

How easily a risky plugin can be swapped out. RAI 80+ means clean replacements exist; below 50 means custom dev is the alternative.

Patterns from a year of plugin incidents

1. The "official" WooCommerce extensions on WooCommerce.com have a higher PVR than the WordPress.org-hosted equivalents. Surprising; explanation seems to be that WooCommerce.com listings have less frequent independent security review than the .org repository's automated scanning.
2. Form plugins are the single most-attacked category in incident response. 60+% of WP hacks we've responded to in the last 18 months trace back to a forms-plugin RCE. PVR captures this.
3. Page builders bundle other vulnerabilities through their addon ecosystems. The headline plugin gets fixed quickly; a third-party addon for the same builder doesn't. The exposure surface is bigger than the plugin metadata implies.
4. Caching plugins are remarkably safe. Three top caching plugins all sit at PVR < 35. Active maintainership, small surface, no user roles or file uploads. The folk-wisdom "disable plugins to be safe" doesn't apply here.
5. The single highest-leverage security move is removing abandoned plugins, not patching active ones. Patches eventually come for active plugins. Abandoned plugins never get patched — and removing them is much faster than auditing them.

Recommendations

For WordPress site owners

Audit your plugin list quarterly. Sort by "last updated" in admin; investigate anything older than 12 months. Remove what you can; replace what you must. Cross-check the rest against WPScan or Patchstack for open CVEs.

For sites where this discipline has slipped — especially long-running WordPress sites with plugin counts above 25 — our maintenance & support engagement runs the audit and clean-up as a quarterly cadence.

For WordPress sites that need real engineering

Build vs install is the framing most teams skip. Many of the highest-PVR categories — page builders, WooCommerce extensions, membership / LMS — can be replaced with custom theme + plugin work that dramatically lowers the attack surface. Our custom WordPress development for business engagement reaches for code rather than plugin sprawl wherever the trade-off favours it.

For sites considering replatform

If your WordPress site is leaning hard on high-PVR category plugins (especially WooCommerce + page builder + LMS), replatforming may be cheaper than maintaining. We covered this in detail in the WordPress performance study.

Limitations

Sample biased toward the top 217 by install count on WordPress.org; commercial-only plugins (not on .org) are not directly scored. CVE data has reporting lag — vulnerabilities exist before they appear in WPScan / Patchstack. The metric weights are tunable; the relative ranking is robust to reasonable weight changes.

The plugin-management discipline that matters most

Sort your installed plugins by "months since last update" tonight. Anything past 12 months is your biggest WordPress security exposure, regardless of how popular the plugin is. The data above maps which categories tend to be most affected — but the discipline of removing abandoned plugins matters more than picking the "best" ones.

About the author

Ritesh — Founding Partner, Appycodes

LinkedIn

Co-authored with Debarshi Dey, Lead WordPress Engineer

Ritesh leads the WordPress practice at Appycodes. Debarshi runs the day-to-day plugin-audit work and was on the incident-response engagement described at the top of this post. The 217-plugin risk model was originally compiled to support quarterly client security reviews; the team has responded to 30+ WP incidents in the last 18 months across the categories above. The companion WordPress performance study covers the second-largest source of WP technical debt: plugin sprawl as a speed problem rather than a security one.

Reviewed by Swati Agarwal, Founding PartnerLast reviewed: May 10, 2026