I Checked the 1,000 Most-Installed WordPress Plugins. Here Is How Well They Are Looked After.

Every WordPress security article says the same thing about plugins: keep them updated, remove the ones you do not use, avoid anything abandoned. Fine. But nobody says how much of the directory that actually describes. Is abandonment a problem at the edges, among the plugins with forty installs, or does it reach the ones running on millions of sites?

I wanted the number, so I pulled the 1,000 most-installed plugins on wordpress.org on 11 September 2026 and looked at the maintenance signals the directory publishes for each one: when it last shipped, which WordPress it claims to be tested on, which PHP it requires, how many people are listed as maintaining it, and how its support forum is doing. This post is what came back. The data is downloadable as a CSV if you want to check the working or slice it differently.

The headline is better than you would guess

Of the 1,000 plugins, 866 have shipped a release in the last six months. Weighted by installs, that is 95% of the roughly 290 million active installs the set represents. The plugins most people actually run are, on this measure, actively maintained.

That is worth saying plainly because the security industry has an incentive to make the ecosystem sound worse than it is. The top of the directory is not a graveyard. The commercial plugins, the big free ones, the ones with companies behind them all ship regularly, most of them monthly or faster.

So if you run a site with ten well-known plugins, the odds that any one of them is abandoned are low. The problems are in the tail, and the tail is where the interesting numbers are.

Where it gets worse

75 of the top 1,000 have not shipped in a year. That is one in thirteen, covering 7.2 million installs. Forty of them have not shipped in two years or more.

Some of those are tiny, finished plugins that do one thing and have no reason to change. A plugin that removes the page title from a template has not needed an update since 2021 and probably never will. That is not abandonment, it is completion, and the directory has no way to tell the two apart.

But the list also contains things that should never sit still:

Limit Login Attempts, the original one, 300,000 installs, last release April 2023, tested up to WordPress 6.2. A security plugin, guarding the login form, that has not been touched through three years of authentication changes including WordPress moving to bcrypt password hashing in 6.8. If you have this installed, you almost certainly meant to install Limit Login Attempts Reloaded, which is a different plugin from a different publisher and is maintained.
PHP Code Widget, 70,000 installs, last release March 2022. It executes arbitrary PHP entered into a widget. That is a webshell with a settings page, and it has been unmaintained for three and a half years.
BackUpWordPress, 80,000 installs, last release April 2024. A backup plugin. The one category where "it still seems to work" is not a test you want to run for the first time during an incident.
Disable REST API, 80,000 installs, last release September 2023. Sits in front of a surface that has changed substantially since.
Health Check & Troubleshooting, 200,000 installs, last release July 2024, tested up to 6.6. This is the plugin the WordPress.org support forums send people to. It is two major versions behind the software it diagnoses.
Hotjar and Facebook Chat Plugin, 70,000 installs each, last releases in 2023 and 2022. Official plugins from large companies that have quietly walked away. A big name behind a plugin tells you who published it, not whether anyone still works on it.

The full list of 19 plugins with 100,000 or more installs and no release in a year is in the CSV. Regenerate Thumbnails, at a million installs, sits just over the twelve-month line.

A fifth have never declared testing on WordPress 7

The directory asks every plugin to state the newest WordPress version it has been tested against. WordPress 7.0 shipped in May 2026 and 7.1 in August. As of this census:

Tested up to	Plugins	Active installs (floor)
7.1, current	574	214.8 million
7.0, one behind	240	49.4 million
6.9 or older, or not stated	186	25.9 million

So 186 of the top 1,000, running on 25.9 million installs, have never claimed to be tested on WordPress 7 at all, four months after it shipped and after a release that rewrote the admin, added the AI client and Connectors, and introduced the Abilities API. Sixty-eight of them are four or more releases behind, which means their last declared test was WordPress 6.7 or earlier, from late 2024.

"Tested up to" is a self-reported field and a lagging one. A plugin can work perfectly on 7.1 while declaring 6.9, and some of the 186 are exactly that. But a maintainer who has not spent the thirty seconds it takes to update that field in four months is telling you something about how much attention the plugin is getting, and the directory shows a warning to anyone installing it. It is the cheapest maintenance signal there is, and 19% of the top 1,000 have not sent it.

Nearly half list a single maintainer

Of the 1,000 plugins, 478 list exactly one contributor on wordpress.org. Together they cover 108.6 million installs.

This one needs a caveat before it means anything. A single listed contributor is often a company account: Elementor lists one contributor and has ten million installs. So this is an upper bound on solo-maintained plugins, not a count of them.

But it is the right upper bound to worry about, for a reason that has nothing to do with whether one person can keep up. A plugin with one owner account is a plugin that changes hands in a single transaction. The Essential Plugin backdoor in April was thirty plugins bought on Flippa from one seller. There was no co-maintainer to notice, no second set of credentials to compromise, no one else with commit access who might have asked what the new owner was pushing. Ownership transfer is invisible from the outside, and a single contributor is the shape that makes it easiest.

Forty-one of the single-contributor plugins have also not shipped in a year, covering four million installs. That is the intersection to watch: unmaintained, one owner, a meaningful install base. It is exactly what a buyer looking for a distribution channel would shop for.

Two smaller things

Minimum PHP. 390 plugins, 39% of the set, declare a minimum PHP version below 7.4, which means they still claim to support PHP versions that stopped receiving security fixes years ago. Only 46 require PHP 8.0 or later. That is not a security flaw in the plugins. It is a measure of how much of the ecosystem is still holding the floor down for sites that should have moved, and why WordPress core itself only got to a 7.4 minimum this year.

Support. Of the 195 plugins with five or more open support threads in the last two months, 20 have resolved fewer than a quarter of them. A support forum where nobody answers is a slower version of the same signal as a stale release date.

What is not in this data

Three things, and they matter.

Closed plugins are gone. When WordPress.org closes a plugin for a security issue or a guideline breach, it drops out of the listing. So this census cannot see the plugins that were abandoned badly enough to be removed. The numbers above are the survivors. Abandonment across the directory as a whole is worse than this.

Ownership changes are not published. There is no field for "this plugin changed hands on this date". The single-contributor count is a proxy for the shape of the risk, not a measurement of it. If WordPress.org published transfer dates, this would be the first column in the table.

Install counts are floors. The directory rounds each plugin's active installs down to a band (10,000, 20,000, 100,000, a million), so every install figure here is a minimum. The top 1,000 cut off at the 30,000 band.

What to do with it

If you run WordPress sites, the useful move is to compare your own plugin list against the signals, not to read the tables and nod. Three checks, in order of how often they will catch something:

Last release. Anything over a year, look at why. Anything over two, plan its replacement now, before the incident that forces you to.
Tested up to. If it does not say 7.x, the maintainer has not looked in four months. That alone is not a reason to remove it. It is a reason to check the support forum for reports of breakage on 7, and to check the release date again.
Contributors. One listed owner is not a problem. One listed owner plus a stale release plus a large install base is the profile of a plugin that will be sold, and you want to know that before the buyer decides what to do with it.

The plugin risk auditor on this site runs the first two of those against any list of slugs you paste in, using the same wordpress.org data as this census. It takes about ten seconds for a typical site.

Method

The wordpress.org plugin API's "popular" listing, ordered by active installs, fetched on 11 September 2026 in four requests of 250. For each plugin: last_updated, tested, requires_php, the contributor list, support_threads and support_threads_resolved, active_installs. Months since release is calculated from last_updated against the fetch date. Tested-up-to lag is counted in minor releases against WordPress 7.1. No plugin code was examined; this is a census of what the directory says about each plugin, which is also exactly what a site owner sees before clicking Install. The CSV has all 1,000 rows and every column used above.

I intend to run it again each quarter. If the numbers move, that is the story next time.

Where this fits

Chapter 8 of the Protect My WP handbook is plugin and theme hygiene: how to vet a plugin before installing it using exactly these signals, the tiered update policy, why install counts hide ownership risk, and the files where a compromised plugin leaves persistence behind. The census is the same checklist run across the directory instead of across one site.

Get the book for £19.