Abandoned and Closed WordPress Plugins: How to Check

WordPress.org closed WP Learn Manager's plugin listing on June 30, 2026, a week before a critical, unauthenticated vulnerability in it went public. The plugin didn't vanish from a single site that already had it installed. It just stopped showing up in the directory and stopped offering updates, while the vulnerable code kept sitting in every wp-content/plugins/ folder that had it. That gap between "closed on wordpress.org" and "gone from your server" is the part most site owners never check.

This guide covers how to check, not just for a plugin you already suspect but for everything installed on a site right now: what closure actually means, what the plugin page and the Plugins API show you, the signs a still-listed plugin is abandoned in every way that matters, and a short routine to run the check across an entire install.

What "closed" actually means on wordpress.org

A plugin listing on wordpress.org can be closed for two broad reasons. The developer handbook states it plainly for the security case: "Should a plugin be found to have security issues, it will be closed until the situation is resolved." The other path is a guideline violation, where "violations may result in plugins or plugin data being removed from the directory until the issues are resolved."

Closing a listing does three things. It pulls the plugin out of search and browse results, so nobody finds it as a new install. It stops offering the plugin as a download, so a site that doesn't already have it can't add it. And it stops surfacing updates to sites that already have it installed, because there's no longer a public release for WordPress core's update checker to find.

What it doesn't do is remove the plugin from your server. If you installed it before the closure, the files stay exactly where they are, still active if you had it active, running the same code that got it closed in the first place. Nothing in the default WordPress dashboard flags this for you. The plugin just quietly stops appearing to have updates, the same way a plugin with no news at all looks.

What a closed plugin's page (and the API) show you

Visit a closed plugin's page and you'll see a banner instead of the usual download button. Creative Mail's listing, closed on May 14, 2026, reads: "This plugin has been closed as of May 14, 2026 and is not available for download. Reason: Security Issue." Closures before January 2018 don't carry a date. Closures younger than 60 days show the notice without the reason attached, since the plugins team gives the developer a window to respond before the public reason appears.

The Plugins API tells the same story in a way you can script. We queried it directly for this guide rather than describing behavior we hadn't checked:

curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=creative-mail-by-constant-contact"
# HTTP 404: {"error":"closed","name":"Creative Mail ...","description":"This plugin has been closed as of May 14, 2026 ...","closed":true, ...}

curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=elementor-pro"
# HTTP 404: {"error":"Plugin not found."}

curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=akismet"
# HTTP 200: full plugin record

Both Creative Mail and WP Learn Manager come back as HTTP 404 with a JSON body whose error field reads closed, along with the same closure notice the plugin page shows. A slug that was never in the directory, such as a premium plugin sold from its vendor's site, also returns 404, but its error reads Plugin not found. Akismet, an actively listed plugin, returns 200 with its full record. The status code alone can't separate a closed plugin from a premium one, so the routine below reads the error field. Quote the URL in your shell so the brackets in request[slug] don't get treated as glob characters.

Signs a still-listed plugin is abandoned

Most abandoned plugins never get closed. The developer just stops working on them, and the listing sits there looking normal to anyone who doesn't check the details.

• "Last updated" age. Every plugin page shows a last-update date. A plugin that hasn't shipped a release in over a year isn't automatically unsafe, but it's a plugin nobody is actively watching for new vulnerability classes either.
• The compatibility warning. Once a plugin's readme falls three or more major WordPress releases behind on its "Tested up to" field, the page displays: "This plugin hasn't been tested with the latest 3 major releases of WordPress." That's a direct readout of neglect, not a guess.
• Unanswered support threads. A support forum with open questions stretching back months, especially ones asking whether the plugin is still maintained, tells you the developer isn't reading them, or isn't replying if they are.
• No response to a reported flaw. A plugin still listed weeks or months after a CVE against it went public, with no new version in the changelog, is the strongest tell of all. The listing being open doesn't mean anyone is behind it anymore.

None of these alone proves abandonment. Stacked together on the same plugin, they tell you whether waiting for a fix is a real plan or wishful thinking.

Audit every installed plugin with WP-CLI

Checking one plugin you already suspect is easy. Checking all of them is the part that actually catches something, because the plugin that quietly went dark two years ago is rarely the one you'd think to look up. This loop reads every installed plugin slug, active or not, and flags the ones the Plugins API no longer knows about:

wp plugin list --field=name | while read -r slug; do
  body=$(curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=${slug}")
  case "$body" in
    *'"error":"closed"'*) echo "CLOSED: $slug" ;;
    *'"error":"Plugin not found."'*) echo "NOT ON WORDPRESS.ORG: $slug" ;;
  esac
done

wp plugin list --field=name prints one slug per line for every plugin in wp-content/plugins/, regardless of whether it's active. The loop requests each slug's record from the same API endpoint checked above. CLOSED means wordpress.org pulled the listing. NOT ON WORDPRESS.ORG usually means a premium or custom plugin that was never in the directory; those need a licence and vendor-changelog check instead, which our guide to expired premium plugin licences covers.

A CLOSED result only catches full closures. It won't flag a plugin that's still listed but neglected, so run it alongside a manual look at the "Last updated" date and the three-major-releases warning for anything the loop leaves clean but you're still unsure about.

How our vulnerability database handles a plugin with no patch

WP Vanguard's vulnerability database records a fixed-in version for every disclosure we track. When there isn't one, we don't drop the entry or hide it. The public listing for that flaw shows "No patched version reported" in place of a version number, so a no-patch vulnerability stays visible instead of quietly falling out of the dataset.

That's a narrower claim than it might sound like. "No patched version reported" tells you the flaw doesn't have a fix yet. It doesn't tell you whether wordpress.org has closed the plugin's listing, and our scanner doesn't check directory status on its own. It checks the plugin versions installed on your site against known vulnerabilities in our database. If a plugin is quietly abandoned but has no logged CVE, that won't surface as a finding, which is exactly why the manual signs above and the WP-CLI loop still matter even if you're already scanning regularly.

Replace, remove, or mitigate: making the call

Once you've confirmed a plugin is closed or effectively abandoned, three options are on the table, roughly in the order you should consider them.

Replace it when a maintained alternative does the same job. Jetpack's own resource page pointed Creative Mail users to MailPoet before the plugin was even closed; that's the easy case, where the vendor already told you where to go.

Remove it when nothing depends on it, or when a replacement is ready. Deactivating alone isn't enough: it stops the plugin's hooks from registering, which closes off any vulnerable AJAX endpoint immediately, but the files stay on disk and a careless reactivation brings the risk straight back. Delete the plugin outright once you're done with it:

wp plugin deactivate PLUGIN_SLUG
wp plugin delete PLUGIN_SLUG

Check for leftover database tables and options afterward. Plugin deletion through WP-CLI removes files, not necessarily everything a plugin wrote to wp_options or its own custom tables, particularly if it shipped without an uninstall.php.

Mitigate, as a last resort, only when you genuinely can't remove the plugin yet: a migration that needs more time, or functionality nothing else replaces. Restrict access to the specific vulnerable request at the web server or firewall level, narrow which roles can reach it, and set an actual deadline for replacing the plugin. A mitigation without a deadline turns into the permanent fix nobody chose on purpose.

Related guides: how to check your plugins for known vulnerabilities, verifying an update is genuine, and our weekly patch list. For the broader hardening steps every site should have regardless of any one plugin, see our WordPress security checklist. For a deeper look at what "no patch available" means for one specific, still-exploitable flaw, our Creative Mail vulnerability writeup and our WP Learn Manager deactivate-or-delete breakdown both walk through a real, closed-plugin removal end to end.

Run a scan on your site to check every installed plugin's version against our vulnerability database while you're auditing what's abandoned.

References

• WordPress.org Plugin Handbook: Detailed Plugin Guidelines
• WordPress.org Plugin Handbook: Alerts and Warnings
• WordPress.org: Creative Mail Plugin Page (Closed, "Security Issue")