How Many WordPress Plugin Vulnerabilities Are There? 28,076 Since 2023

28,076 WordPress plugin vulnerabilities were disclosed between January 2023 and August 2026. Ranked by raw advisory count — which is how every "most vulnerable plugins" list does it — the result mostly measures popularity. Divide by install base instead and the table almost completely inverts. And 45.7% of the advisories we could match name a plugin WordPress has since removed from its directory, which does not uninstall it from anyone's site.

A plugin installed on ten million sites attracts researchers. One installed on four hundred does not. Counting advisories without dividing by install base produces a list of well-examined plugins and calls it a list of dangerous ones.

So we pulled 28,076 CVE records from the National Vulnerability Database — every advisory filed by Patchstack and Wordfence, the two CNAs that cover the WordPress ecosystem, from January 2023 to August 2026 — and crawled the WordPress.org plugin directory for the denominator: 53,545 plugins holding 326,662,480 active installs. The full dataset is available as CSV.

Divide by install base and it is a different table

Restricting to plugins with at least 10,000 installs and at least one advisory leaves 1,015 plugins. Ranked one way and then the other, the two top tens share exactly one entry.

The dangerous plugins are not in either list

This one we found by accident. Thousands of advisories named plugin slugs that would not join to the directory at all. The obvious explanation was a broken crawl, so we queried fifteen of them directly against the WordPress.org plugin API.

All fifteen returned 404. They are not crawl gaps. They are plugins WordPress.org has removed.

Counted across the whole corpus: 4,876 of 10,678 slug-resolved Patchstack advisories — 45.7% — name a plugin that is no longer in the directory. That is 3,934 distinct plugins. Applying a deliberately conservative test, requiring the slug to contain a hyphen and exceed four characters, still leaves 2,623.

This is the part that matters, and it is the reason every published ranking is quietly wrong: those plugins are still installed. Closing a plugin removes it from the directory. It does not deactivate it, does not uninstall it, and does not put a notice in anyone's dashboard. A site running a closed plugin keeps running it, will never receive another update, and is told nothing.

Every "most vulnerable plugins" list is therefore a survey of survivors. The plugins that were dangerous enough to be pulled are the ones that dropped out of the sample.

A 30x spread between the safest and riskiest categories

Grouping by the directory's own tags and dividing advisories by the category's total install base gives a rate that is comparable across categories:

Membership and LMS plugins carry thirty times the advisory rate of security plugins. That is not a subtle difference in risk profile. If you are running a course platform or a paid-membership site on WordPress, you are operating in the worst-behaved corner of the ecosystem.

Security plugins coming last is worth a moment. It is what you would hope for, and it is not guaranteed — a security plugin with a vulnerability is a particularly bad object. The data says the category broadly earns its trust.

Abandonment is real but concentrated

• 25,209 plugins — 47.1% of the directory — have not shipped an update in 24 months. That number gets quoted a lot and sounds alarming.
• Those plugins hold 9,667,140 active installs: 3.0% of the total. Almost all abandonment is in the long tail, on plugins nobody runs.
• 693 abandoned plugins carry a published advisory, across 1,929,330 active installs. This is the population that is actually exposed.

Under two million installs is a far smaller problem than "half the directory is abandoned" implies, and a far more actionable one. It is a specific list of plugins on a specific set of sites.

Method

• Advisories: the NVD CVE API 2.0, scoped to the two WordPress-ecosystem CNAs — Patchstack (`audit@patchstack.com`) and Wordfence (`security@wordfence.com`) — from 1 January 2023 to 22 August 2026. 17,315 and 10,761 records respectively.
• NVD caps a query at 120 days and returns an empty result, without an error, for anything wider. Requests are chunked at 110 days.
• Plugin slugs: Patchstack embeds the WordPress.org slug in its advisory text; Wordfence gives a display name, which is matched back to a slug through the directory's own name index. 14,885 advisories resolved, across 8,826 plugins.
• Install base: the WordPress.org plugin API, crawled twice and unioned — 53,545 plugins.
• Rates are computed only for plugins with at least 10,000 active installs, below which the bucketing makes a per-million figure meaningless.

Limitations

`active_installs` is a bucket floor, not a count. WordPress.org reports 10,000 for anything between 10,000 and 19,999. Per-plugin rates built on it are therefore upper bounds, and all ten plugins in the top-by-rate table sit in that lowest bucket, where the true figure could be half what we show. Category rates aggregate across buckets, so the bias is shared and the ranking between categories holds even though the levels are upper bounds.

The closure rate is a Patchstack-only measurement. Wordfence advisories give a display name that we resolve by looking it up in the directory — so a closed plugin can never resolve on that side, by construction. Reporting a blended figure would understate it.

Directory coverage is 53,545 of 66,142 plugins. The plugin API pages an unstable sort, so a single crawl sees about 74% of it. This does not move any number here: the 4,579 plugins that only the second pass found hold 182,120 installs between them — 0.056% of the total — and every metric filters at 10,000 installs anyway. Install-mass coverage is above 99.9%.

Advisory counts are not incident counts. A plugin with a high rate has been examined and reported on. Silence is not safety, and some of the quietest plugins in this dataset are quiet because nobody has looked.

What to actually do with this

The practical finding is not "WordPress is insecure." It is that the failure mode nobody checks for is the plugin that was removed from the directory while still active on the site. Update counts look fine. The dashboard is quiet. There is no update, because there is no longer anything to update from.

Auditing for it is straightforward and almost nobody does it: take the active plugin list, query each slug against the WordPress.org API, and flag every 404. On a site carrying a few dozen plugins it takes minutes, and it is the single highest-yield check available. If a site matters commercially, that check belongs in a scheduled routine rather than in someone's memory — which is the substance of a WordPress maintenance and development engagement rather than a one-off scan.