A WordPress plugin is probably abandoned when it has not shipped a release in a long time, no longer declares support for current WordPress and PHP versions, and nobody answers support threads. No single signal proves it. Check the directory status, the last update date, and the maintainer's response, then decide whether to replace it.
What "abandoned" means in practice
There is no official label. A plugin is abandoned when its author has stopped maintaining it, so a security flaw found tomorrow would not get a fix. That is the risk you are measuring: not age, but the chance that nobody patches the next bug.
Age alone misleads. A small plugin that does one thing can be finished and stable. A plugin that touches forms, uploads, payments or logins and has not changed in years deserves more suspicion.
Three signals you can check in a minute
| Signal | Where to see it | What worries you |
|---|---|---|
| Directory status | The wporg_status field in WP-CLI | A plugin that is no longer listed or is closed |
| Last release | The wporg_last_updated field | Long gaps on code that handles input |
| Declared compatibility | The tested_up_to, requires and requires_php fields | Nothing tested against current WordPress or PHP |
WP-CLI exposes all of these as optional fields on the plugin list command. This prints the first two for every installed plugin:
wp plugin list --fields=name,version,wporg_status,wporg_last_updated,tested_up_to,requires_php
Run it on a copy of the site or on production with read only access. It lists data and changes nothing.
Steps to take on each suspect plugin
- Confirm the plugin is still listed on WordPress.org. A plugin that is gone from the directory has either been closed or never was there, and the guidelines say plugins with security issues are closed until resolved.
- Read the last release date and compare it with the date of the last WordPress major release your site runs.
- Look at the support forum for unanswered security reports.
- Check whether the plugin is premium. Premium plugins update from vendor servers, so the directory fields will not tell you the whole story. Ask the vendor for their support policy.
- Decide: keep and monitor, replace, or remove.
Replacing without breaking the site
Find out what the plugin does on the live site. Many sites carry plugins whose feature nobody uses any more. If a feature is still used, find a maintained plugin or move it into a small piece of reviewed code. Test the swap on staging first, because data stored by the old plugin may not migrate.
If you cannot replace it yet, reduce exposure. Restrict who can reach the feature, deactivate it where possible, and watch advisories for it. Removing it beats waiting.
Keep an inventory so this is not a one time job
Abandonment is a drift problem. A plugin that was fine last year may not be fine now. Keep a list of every plugin, its version, and the date you last checked it. Safeguard can scan a repository for dependency manifests and produce an SBOM, and there is a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how every component and version appears in one list, which is the starting point for spotting stale ones.
Quick check
Is a plugin that has not updated in two years always unsafe?
No. Simple plugins can be finished. Weigh age against what the plugin touches: input handling, uploads, payments and authentication raise the stakes.
Does WP-CLI tell me about vulnerabilities?
No. It reports directory status, version and update dates. Vulnerability data comes from advisory sources, so combine both.
Sources
Last reviewed: 19 October 2026.
