Study of 8,010 vulnerable WordPress plugins finds 3,780 quietly pulled from directory

An independent analysis published on dev.to has assembled a dataset of every WordPress plugin with a publicly documented vulnerability since 2023 and cross-checked each one against the official plugin directory. The dataset covers 8,010 distinct plugins and 15,534 vulnerability records, and its headline finding is about visibility: when a plugin is removed from the wordpress.org directory, the site owner gets no dashboard warning and no email. The plugin simply stops receiving updates while its code keeps running.

What the numbers show

According to the analysis, of the 8,010 plugins with a documented vulnerability since 2023:

• 3,780 have been removed from the wordpress.org plugin directory. Removal halts the update channel but does not uninstall anything, so affected sites keep executing the plugin.
• 277 of the removed plugins had a critical flaw on record, defined as CVSS 9.0 or higher, before they were pulled.
• 2,115 plugins with a known vulnerability are still installable today and have not been updated in more than twelve months, together accounting for roughly 6.7 million active installations.

The author singles out the removal mechanism as the most surprising result: it is essentially invisible to the person operating the site.

How the dataset was built

The pipeline relies on two public sources and no paid APIs. Vulnerability data comes from the GitHub Advisory Database, a git repository that mirrors CVE records, including the Patchstack and Wordfence assignments that account for nearly all WordPress plugin CVEs. A shallow, sparse clone of the advisory folders yields raw JSON containing the CVE identifier, CVSS vector, CWE IDs and reference URLs. The plugin slug is not a first-class field in those records, so the author recovers it with regular expressions applied to the Patchstack and Wordfence reference URLs, which attributes the large majority of advisories to a specific plugin.

Maintenance signals come from the wordpress.org plugin information API, which reports install counts, last-updated dates, tested-up-to versions and support-thread resolution ratios. One methodological trap the author flags: a 404 from that API is ambiguous. It can mean the plugin was removed, or that it is a commercial plugin never hosted in the directory at all. Disambiguation requires checking the plugin's public page for the closure notice, which also carries the closure date. Skipping that step, the author notes, would wrongly mark a commercial plugin such as WP Rocket as removed.

Why raw CVE counts mislead

A central argument of the analysis is that ranking plugins by vulnerability count is backwards. Large, actively maintained plugins with bug bounty programs accumulate more CVEs than abandoned code that nobody has ever audited, so a raw count punishes responsible maintainers and rewards unaudited ones.

Instead, the scoring model combines two axes. Vulnerability load uses time-decayed severity with an 18-month half-life, weighted toward unauthenticated and recently recurring issues, so the score describes the plugin's current situation rather than its worst historical moment. Maintenance considers update age, the tested-up-to gap, unresolved support ratio and directory-removal status. Crucially, an absence of CVEs is never treated as a positive signal, since it often means the plugin has never been examined.

Practical takeaways for site owners

The author's recommendations for anyone running WordPress sites are straightforward:

• Check whether any installed plugin has silently left the directory, because no warning mechanism exists.
• Remember that deactivating a plugin is not removing it; the files remain reachable on disk, so replace and delete them.
• Treat a "tested up to" version three major releases behind as a maintenance red flag even without a known CVE.

The full index, one page per plugin with a CVE timeline and the scoring method spelled out, is published free at xuro.net, with every input and weight disclosed on the theory that a score you cannot audit is not worth citing.

Why it matters

WordPress underpins an enormous share of the web, and plugins are its primary attack surface. This dataset quantifies a structural failure mode that is easy to overlook: the update channel itself can silently break, leaving millions of installations running code that will never be patched. It is also a useful template for reproducible security research, built entirely from public data with an auditable methodology rather than proprietary feeds. For agencies and administrators managing many sites, the three-point checklist above is cheap to act on immediately.