---
title: "New WordPress Plugins: 80% of This Year's Have Under 10 Installs"
slug: "new-wordpress-plugins-installs-and-vulnerabilities"
description: "We scanned all 74,360 plugins in the WordPress directory. New WordPress plugins are flooding in, but most are never installed, and disclosures follow installs."
date: 2026-10-04
author: "WP Vanguard Team"
category: "Research"
tags: ["new-wordpress-plugins", "wordpress-plugin-directory", "plugin-installs", "plugin-security", "vulnerability-trends"]
featured_image: "/images/blog/new-wordpress-plugins-installs-and-vulnerabilities.jpg"
---

The WordPress plugin directory lists 15,901 plugins added in 2026. All of 2025 added 6,014. If you've felt like new WordPress plugins are everywhere, the numbers agree with you. Anyone with an AI coding tool can build a plugin in an afternoon, and directory review is now the only slow step.

We wanted to know what that flood means for a site owner, so on October 4 we pulled every plugin in the directory (74,360 of them) and matched them against our vulnerability database. Two findings stood out. Most of the new plugins never reach a real site, and the plugins that collect security disclosures are the ones with the most installs, not the newest.

```stat
{"value": "66", "label": "of the 15,901 plugins added this year have reached 1,000 installs", "note": "WordPress.org plugin directory, scanned October 4."}
```

## How we counted

We read all 745 pages of the directory's "newest" listing through the WordPress.org plugin API. For each plugin we kept the date it was added and its active-install figure, which WordPress.org publishes in rounded steps: under 10, 10+, 100+, 1,000+ and so on.

The listing comes from the public `query_plugins` action of the WordPress.org plugin API with `browse=new`, 100 plugins per page, so anyone can repeat the count and check our totals.

For security, we took every high or critical plugin disclosure in our database published between July 5 and October 4: 1,204 disclosures across 817 plugins. We matched those to the directory by plugin slug. 271 of the 817 aren't in the public listing at all, because they're closed, removed or sold elsewhere, so the comparisons below use the 546 that are.

One limit up front. The directory can't tell us how a plugin was written, so we can't separate AI-built plugins from the rest. We're measuring new plugins, and the timing fits AI tools without proving they're the cause.

## The flood is real, and mostly unseen

Weekly additions climbed from 461 in the week of May 25 to 784 in the week of September 21, with one low week in early August. Closed plugins drop out of the listing, so older weeks are undercounted and the true rise is a little smaller than it looks.

The more telling number is what happens after publication.

```ring
{"title": "Added in 2026", "percent": 80, "value": "80%", "label": "have fewer than 10 installs", "note": "12,651 of 15,901 plugins."}
```

| Year added | Plugins listed | Under 10 installs | 1,000+ installs |
|---|---|---|---|
| 2016 | 4,192 | 13% | 15.2% |
| 2019 | 3,731 | 23% | 16.1% |
| 2022 | 3,190 | 30% | 11.0% |
| 2023 | 1,846 | 31% | 9.6% |
| 2024 | 3,314 | 39% | 6.7% |
| 2025 | 6,014 | 49% | 2.7% |
| 2026 | 15,901 | 80% | 0.4% |

Of the 15,901 plugins added this year, 12,651 report fewer than 10 installs. Only 66 have reached 1,000.

Part of that is time. A plugin added last month hasn't had a chance to grow, and old plugins that failed have been closed and removed from the listing. Even so, the pattern is clear. Publishing a plugin has become cheap, and finding users hasn't.

## Disclosures follow installs, not age

Here's how many plugins in each size band had a high or critical disclosure in the 90 days we looked at.

| Active installs | Plugins | With a disclosure | Per 1,000 plugins |
|---|---|---|---|
| Under 10 | 26,655 | 5 | 0.2 |
| 10 to 99 | 30,913 | 34 | 1.1 |
| 100 to 999 | 9,783 | 54 | 5.5 |
| 1,000 to 9,999 | 4,825 | 193 | 40 |
| 10,000 to 99,999 | 1,718 | 175 | 102 |
| **100,000 or more** | **466** | **85** | **182** |

```bars
{"title": "High or critical disclosures per 1,000 plugins, by active installs", "highlight": "100k+", "data": [
 {"label": "Under 10", "value": 0.2},
 {"label": "10 to 99", "value": 1.1},
 {"label": "100 to 999", "value": 5.5},
 {"label": "1k to 9.9k", "value": 40},
 {"label": "10k to 99k", "value": 102},
 {"label": "100k+", "value": 182}
], "note": "Last 90 days, 546 plugins matched to the directory."}
```

> [!KEY]
> Disclosures follow installs, not age. A plugin nobody runs hasn't passed a security audit, it hasn't had one.

Almost one in five plugins with 100,000 or more installs had a high or critical disclosure in three months. For plugins with fewer than 10 installs, it's about one in five thousand.

By year added, the 2026 plugins come out at 0.8 disclosures per 1,000 plugins and 2025 at 3.2, against roughly 7 to 15 for most older years. That's the same install effect, not proof that new code is safer. Plugins that nobody runs don't get audited, so no disclosures doesn't mean no bugs.

## What the numbers can't tell us

The install bands are rounded, and the top band starts at 100,000, so a plugin with 120,000 installs and one with 4 million sit in the same row. Our data can't split that band, so the gradient at the top may be steeper than the table shows.

A disclosure also isn't a measure of how careful the author was. A plugin that gets audited a lot will collect disclosures, and a plugin that fixes bugs quietly may collect none. A high count can reflect attention as much as carelessness, and we haven't tried to separate the two.

The 271 plugins we couldn't match are worth a second look. They had a high or critical disclosure and then left the public listing, so any comparison that only uses the live directory flatters the picture. We treat that gap as a limit on the data and draw no conclusion from it.

## Reading the table as a site owner

Take the 1,000 to 9,999 band. About 4 in 100 of those plugins had a serious disclosure in three months. If you run ten plugins from that band and the rate holds for each, the chance that at least one of them had a disclosure in a given quarter is about one in three, and that's before counting anything bigger.

Now take the under-10 band. The risk to you is close to zero, but so is the evidence. Nobody has looked, nobody has reported, and the author may be the only person who has ever read the code. That isn't safety, it's silence.

This is why install count is a useful first filter and a poor last one. It tells you whether other people are exposed alongside you and whether researchers are likely to be watching. It doesn't tell you whether the code is any good.

## A five-minute check before you install a new plugin

None of this needs a tool. Open the plugin's page on WordPress.org and look at four things:

- **Added and last updated.** A plugin added last week with no updates hasn't been tested by anyone but its author. A plugin not updated in a year may be abandoned.
- **Active installs.** Under 10 means you'd be an early tester, not a customer.
- **Changelog.** Look for security fixes. A changelog that mentions escaping, nonces or capability checks shows the author knows what to look for.
- **Support threads.** Unanswered threads from months ago are a warning. A reply from the author within a few days is a good sign.

Once it's installed, check it against known disclosures on a schedule. From a shell, `wp plugin list --fields=name,version,update` shows what you're running and what has an update waiting.

## What this means for site owners

The flood doesn't change where your risk sits. It sits in the widely installed plugins you already run. Our recent update on [unauthenticated stored XSS](/blog/unauthenticated-stored-xss-wordpress-plugins) shows 14 plugins with 100,000 or more installs patching the same bug class in under two weeks.

The flood does change how you should judge something new. Cheap publishing means more plugins to choose from and less evidence about any one of them. A plugin with no installs, no reviews and no history hasn't failed an audit. It hasn't had one. Before you put it on a production site, look at when it was added, when it was last updated, whether the changelog mentions security fixes, and whether its author answers support threads.

Our guides on [checking plugins against known vulnerabilities](/blog/check-wordpress-plugins-for-known-vulnerabilities) and [abandoned and closed plugins](/blog/abandoned-wordpress-plugins-closed-plugin-check) walk through each check with WP-CLI.

Our scanner matches your plugin versions against known disclosures, so it can't judge a plugin nobody has reviewed yet. For those, the safest rule is the old one: fewer plugins, and more caution about the new ones. Our look at [where WordPress's vulnerability numbers come from](/blog/is-wordpress-secure-vulnerability-data) explains why the count of disclosures only ever describes the plugins people are looking at.

[Run a free scan](/#scanner) to check the plugins on your site against our database of known vulnerabilities.

## Sources

- [WordPress.org: newest plugins in the directory](https://wordpress.org/plugins/browse/new/)
- [WP Vanguard vulnerability database](/vulnerabilities)