WordPress Closed That Plugin. Your Dashboard Still Says It Is Fine.

If WordPress.org has closed a plugin that is running on your website, remove it. Not at the weekend. Today.

That is blunter than I normally get. The reason I hold the position is that a closed plugin is not a maintenance job you have fallen behind on, it is a maintenance job that has been cancelled. No update is queued for you. Nobody is working on a fix. There is no date in the future on which the situation quietly resolves itself.

Going through plugin inventories during our operations review this week, the thing that keeps surfacing on sites we take over from other providers is not software that is out of date. It is software that cannot be updated at all, sitting on sites whose owners are confident everything is patched, because the plugins screen in their WordPress admin has said so every day for two years.

What Closure Actually Does

WordPress.org runs the directory that most free plugins are distributed through. When the Plugins Team closes one, the official Plugin Developer FAQ describes the effect plainly: "the page shows as closed and the zips are no longer generated. No one will be able to download the plugin via the website, nor will they be able to install it via the WordPress admin" ^[1].

Read that as an operator and the consequence lands immediately. No zip means no update package, and no update package means the version sitting in your production environment on the day of closure is the last version that will ever exist for you. Your copy keeps running. It keeps working exactly as it did before, which is the part that catches people out.

Apply it to something real. A contact or quote form plugin closed over a security issue carries on accepting submissions perfectly well. The flaw that got it closed does not disappear because the directory page did. Once a vulnerability is publicly documented it is documented for everyone reading the disclosure feeds, including the people running automated scans against every WordPress site they can reach. Your form still works. That is not evidence you are fine, it is evidence that nothing has come looking yet.

Nothing in Your Admin Screen Changes

This is where the design of the system works against the owner. Open Plugins in WordPress and a closed plugin looks identical to a healthy one. No banner. Nothing in red. The update prompt never appears, because the update API has nothing left to say about that plugin.

Patchstack, whose researchers have written about the security implications of repository closures, make the point that closed plugins carry on presenting as up to date, which leaves owners with a false sense of security ^[2]. I would put it more bluntly than that. The absence of an update notice is being read as a clean bill of health. It is not one.

Consider a tool-hire depot in Cavan whose online quote form runs on a plugin that was closed a year and a half ago. Quotes still arrive by email. The form still submits. Nobody on the team has any reason to look, because everything behaves normally and the plugins list is tidy. The only visible signal that anything changed lives on a page on WordPress.org they have never had cause to open.

A Closure Is Not Always a Hack

I want to be fair to plugin developers here, because the word "closed" sounds like an accusation and frequently is not one.

Sixty days after a plugin is closed, WordPress.org publishes the reason, drawn from five categories set out in the Plugin Handbook: Author Request, Guideline Violation, Licensing/Trademark Violation, Merged Into Core, and Security Issue ^[3]. Only one of those five is a security event. Merged Into Core is close to good news, because it means the functionality is now part of WordPress itself. A trademark dispute tells you nothing at all about the code quality.

Abandonment is the quiet one. The same FAQ notes that the team may close a plugin without notifying anyone if no code has been pushed to its repository in six months, if the developer's repository access has been broken for more than a year, or if the readme file says the plugin is deprecated ^[1]. Nobody did anything wrong. Somebody simply stopped, and the directory eventually noticed. Those are the closures that worry me most, because if a flaw turns up in one of those plugins next spring, there is no developer left to ship the patch.

One thing a plugin audit cannot do: tell you whether a closed plugin was already exploited on your site before you removed it. Removal stops the exposure going forward. It is not a forensic check. If the published reason reads Security Issue and the plugin handled logins, payments, or file uploads, treat removal as step one, then have the site scanned for malware and rotate your administrator passwords. The WordPress security team does not publish details beyond the category label and says as much, so you will often be making that call on two words. Make it anyway.

WordPress Built a Gate. It Only Covers the Front Door.

Something genuinely good happened in the plugin directory this year, and it deserves the credit before I take the other side.

Since 5 June, every plugin and theme release published to WordPress.org sits in a cooldown window before it is distributed through the update API. The Plugin Review Team has that window set at six hours and published the results on 9 September. During the cooldown the changes in each release are analysed by several AI models together with Jetpack Scan, the results are cross-checked, and the findings are combined into a security score. In the team's own words, "releases with a high risk score are blocked automatically as soon as the security review finishes, and all plugin committers receive an email with the findings" ^[4].

It has already earned its keep. On 28 July the review caught a backdoor committed to a release of a plugin with roughly 20,000 active installations. That compromised version never reached a single site through the update API, because it was still inside the cooldown when the score came back. The plugin was closed for downloads 26 minutes after Wordfence notified the team.

Good operations work, and I am glad it exists. Now read it again, because every protection in that description operates on a release.

A plugin that has been closed produces no releases. The one nobody has touched since 2022 produces none either. Neither enters the cooldown, neither gets scored, and neither can be blocked, because there is nothing there to block. The gate is on the front door and it is a good gate. What worries me is already inside the building: installed, active, and invisible to the entire system.

Auditing Your Plugin List in Five Steps

List. Open Plugins in your WordPress admin and write down every plugin, including the deactivated ones.

Verify. For each name, open its page on WordPress.org. A closed plugin shows a notice saying it has been closed and is no longer available for download, with the date, and after two months it shows the reason as well.

Date it. For the plugins still in the directory, look at when each was last updated. Anything untouched for two years or more belongs on a watch list even if nobody has closed it yet.

Replace. Find a maintained alternative, install it in a staging environment, and verify the job the old plugin did still gets done before you touch production.

Delete. Remove the old plugin entirely once the replacement is live. Deactivating is not the same thing, for reasons worth spelling out.

Deactivated Is Still Installed

Deactivation tells WordPress to stop loading a plugin during the normal request cycle. The files stay exactly where they were, in your plugins directory, on your server. Some classes of vulnerability are reached by requesting a plugin file directly over HTTP rather than going through WordPress at all, and a file still sitting on disk is still there to be requested. Deleting removes the directory. That is the difference between code that cannot run and code that has merely been asked not to.

Ireland's National Cyber Security Centre puts the general principle to small businesses without any hedging: "If the manufacturer stops offering support for either the hardware or software you are using in the business, it is time to replace it with a more up-to-date alternative" ^[5]. A closed plugin is software whose manufacturer has stopped offering support. The same logic applies a layer further down, to the server software underneath your plugins, which reaches end of life on its own schedule and is usually somebody else's job to watch.

What a Host Should Be Doing About This

Before I name any platform, it is worth setting out what a competent answer looks like, because you can hold your current provider to it whoever they happen to be.

A host that takes this seriously should know what is installed across the sites it runs, rather than treating the contents of your WordPress as your problem alone. Vulnerability feeds and closure notices need watching by someone whose job that is, not by a customer who happens to read the right blog.

Staging should come as standard, so that swapping a plugin out is a rehearsed change and not a live experiment on your busiest page. Every update should be preceded by a restorable backup, which turns a bad replacement into a rollback rather than a rebuild. And the protections that matter most should run at server level, where they keep working regardless of whether any particular plugin ever gets patched again.

Web60 is built to that shape. One-click staging, automatic nightly backups with one-click restore, safety snapshots taken before updates and restores, server-level hardening with fail2ban, and automatic malware scanning, all of it running on Irish infrastructure our own operations team maintains. None of that stops a plugin being abandoned by its author. What it does is turn removing one into a twenty-minute job with a rollback behind it, rather than a decision you keep postponing because you are not sure what will break. The wider routine this sits inside is set out in our complete WordPress security and backup guide for Irish websites.

Now the honest limit. If you are running a heavily customised WooCommerce build with a retained developer and a monthly maintenance contract, a premium managed WordPress provider with per-site retainers and a named engineer will handle plugin replacement more thoroughly than any automated process, because a human being is paid to make judgement calls about your particular stack. That is a real advantage and it is priced accordingly. Most owner-operators are not buying that level of attention, and they should not have to buy it simply to avoid running code that nobody maintains.

Conclusion

Closed plugins do not announce themselves the way a defaced homepage does. They are worse in one narrow respect: a defaced homepage gets fixed, whereas a closed plugin has no resolution date at all, and every month it stays installed is another month in which a security decision is being made by default.

The check itself is not hard. Open your plugins screen, write the list down, and spend twenty minutes with the directory pages. Most owners find nothing, which is a good answer and worth having in writing. The ones who do find something usually find it on a plugin they had forgotten was installed, which says something about how long it had been sitting there quietly. Either way you will know, and that was never a thing your dashboard was built to tell you.

Frequently Asked Questions

How do I know if a WordPress plugin has been closed?

Open the plugin's page on WordPress.org, at wordpress.org/plugins/ followed by the plugin's name. A closed plugin displays a notice stating it has been closed and is no longer available for download, along with the closure date. Sixty days after closure, that notice is updated to show the reason. Your WordPress admin screen will not tell you any of this, which is why the directory page is the check that matters.

Does a closed plugin stop working on my site?

No. The copy installed on your site keeps running exactly as it did before. Closure affects distribution only, so no download files are generated and no updates are delivered. That is precisely why closures go unnoticed for so long: nothing visibly breaks, and the plugins screen shows no warning.

Is a closed plugin always a security problem?

No. WordPress.org publishes five closure reasons: Author Request, Guideline Violation, Licensing/Trademark Violation, Merged Into Core, and Security Issue. Only one of those is a security event, and Merged Into Core means the feature is now part of WordPress itself. What every closure has in common is that the plugin will never receive another update, which is reason enough to replace it.

Can I keep using a closed plugin if there is no replacement?

You can, and occasionally there genuinely is no equivalent available. If you take that route, treat it as a temporary position with a review date rather than a permanent one. Keep the plugin's role as narrow as possible, make sure the site is backed up nightly so you can restore quickly, and keep looking for an alternative. Code that receives no security updates carries a risk that only grows with time.

Does deactivating a closed plugin make it safe?

Not entirely. Deactivation stops WordPress loading the plugin on normal page requests, but the files remain on your server, and some vulnerabilities are exploited by requesting a plugin file directly. Delete the plugin once a replacement is running. Deleting also takes it off the list you have to audit next time round.

Sources