WP Packages Now Tracks Mass Plugin Closures

A couple of weeks ago, I was looking at the WP Packages status page and noticed 83 plugins had been closed on WordPress.org within an hour. They all appeared to be from the same vendor: WPFactory. The closures followed a backdoor that exposed 170,000 WordPress sites.

Two days later it happened again with a different vendor: 11 plugins from bPlugins, most with CVEs reported by Patchstack and Wordfence.

I ended up posting gists of these that I happened to see, but thought this should be automated and surfaced somewhere permanent on the site.

Mass closures page on WP Packages

The new mass closures page lists every recent vendor mass-closure event. An event is recorded when the same vendor has two or more plugins closed within a rolling 24-hour window.

Each vendor has its own detail page showing every plugin in the outbreak with the current status of each plugin (active, closed, or tombstoned), pulled live from our package data. If WordPress.org reactivates a plugin, that change is reflected on the page.

There’s also a JSON API at /api/closures and /api/closures/{vendor-slug} and an RSS feed available.

Mass closures are usually related to security

A vendor mass closure is almost always a signal of something serious like a backdoor, a string of unpatched vulnerabilities, or a takedown. Both of the events that prompted this feature were security-related.

WP Packages doesn’t allow closed plugins to be downloaded, which matches WordPress.org’s behavior. WPackagist continues serving closed plugins silently — someone migrating discovered they’d been using one closed 3 years ago. Take a look at how WP Packages compares to WPackagist, and consider migrating. We have a script available to migrate from WPackagist to WP Packages.

The WordPress.org plugins team is fast and acts on these reports quickly, but there’s no public communication from them when a mass closure happens. Not everyone using a vendor’s plugins runs a security plugin or auditing tool. It would be great to see some minimal public disclosure from WordPress.org when this kind of action is taken. Until then, the community at least has a public, timestamped log to point at.

This page only exists because the status checks were already public. The first two mass closures were noticed by glancing at a dashboard, not by anything designed to catch them.

Take a look at the new WP Packages mass closures page, and subscribe to the RSS feed (which can be hooked up to a channel on your team’s Slack) for notifications of new closures.