Does one of your plugins have a Last updated date you’d rather not think about? Searching “is [plugin] still getting updates” is the right instinct. An abandoned plugin can keep working on your site, which makes it easy to leave alone. But “working” and “still getting security updates” are different things.
Why bother? Attackers don’t pick sites, they scan for plugins with known holes, and a plugin nobody patches keeps that hole open for good. Deactivating it isn’t enough either: the files stay on the server, so remove the plugin properly once it’s out of use. So here’s the practical bit: check the signs, decide what to keep, and swap out what you shouldn’t trust.
Check the WordPress.org page first
For a plugin hosted on WordPress.org, open its plugin page and give yourself five minutes. Don’t judge it from a single date. Read the clues together.
Last updated: How long has it been since a release? Open the changelog rather than assuming a recent date means a security fix.Tested up to: Does it cover a recent WordPress version? If it doesn’t cover the latest three major releases, WordPress.org shows a yellow notice saying the plugin may no longer be maintained or supported. That’s definitly a strong hint. A fresh value is weaker evidence: developers can change it in the readme without shipping new code.- The red closed notice: If the page says the plugin has been closed and isn’t available for download, take it seriously. A closure can relate to security, guidelines or an author request; the broad reason appears after 60 days. Existing sites get no update and no dashboard warning just because the plugin was closed.
- Support forum: Look past the resolved-threads counter. Are developers answering recent questions? Are security questions sitting unanswered?
- Changelog and
Advanced View: Read the release history. Entries mentioning security, sanitizing, escaping, nonces or permissions tell you more than years of “bug fixes.” Compare release dates with any vulnerability disclosures you find. - Active installations: A big number isn’t proof of maintenance. If you check again later, note whether the figure is moving, but don’t treat popularity as a security verdict.
That yellow warning deserves a second look, not a panic click. It’s driven by a readme field, so check the actual releases before you decide. The red closure notice is different: you can’t download or install a closed plugin from WordPress.org, and a site already using it won’t be handed a fix there.
Is there a known vulnerability without a fix?
Search the plugin name in the free Patchstack database and Wordfence Intelligence. Open the latest vulnerability entries and look for a fixed-in version. No known fix, or no fixed version listed, means you can’t solve that entry by clicking Update. Check the version you actually have installed, too; a fixed version helps only if you can get and install it.
Why make this a separate check? Patchstack’s State of WordPress Security in 2026 reported that 46% of vulnerabilities didn’t get a developer fix in time for public disclosure. That doesn’t mean every one of those plugins was permanently abandoned. It does mean waiting for an update isn’t always a plan.
If you manage several sites, our vulnerability scanner helps you see what you actually run and what’s flagged. The database entry still matters: read it before deciding whether the issue affects your setup.
What if you bought the plugin elsewhere?
Premium plugins sold outside WordPress.org won’t have those WordPress.org page signals. Go to the vendor’s changelog. Check the last release date, look for security fixes and confirm your licence is active. An expired licence can mean no updates in your dashboard, even if the vendor has shipped them. Find the vendor’s security contact or vulnerability disclosure policy, too.
For EU businesses, there’s another reason to ask. The EU Cyber Resilience Act is pushing commercial software vendors, including commercial plugin sellers serving EU users, to handle vulnerability reports and ship security updates. Its reporting obligations started in September 2026; full obligations begin in December 2027. I wouldn’t treat a missing policy as proof of a bad plugin, but I would ask the vendor who receives security reports.
Doesn’t WordPress check plugin updates now?
Yes, but that solves a different problem. Our post on WordPress.org’s checks before plugin updates reach your site explains the new-release checks. Those checks only help if a release exists. If nobody is maintaining the plugin or shipping a fix, there’s nothing new to check or deliver. That’s the gap you’re investigating here.
What to do with an abandoned plugin
Don’t jump straight to installing a lookalike. First, work out what the plugin does on your site today. A feature you stopped using is easier to remove than replace.
- Not needed? Plan to remove it. Check for old forms, blocks or shortcodes first.
- Already covered? See whether WordPress core, your theme or another plugin you run now handles the job. One less plugin is my favourite replacement.
- Still needed? Look for a maintained alternative with a useful changelog and responsive support.
- Found a fork? Judge its maintainer and release history, not its name. WordPress.org forked Advanced Custom Fields as Secure Custom Fields in October 2024, so forks can happen at scale. A fork with one release and no support isn’t automatically better.
If you must keep it briefly, reduce access to the feature where you can, deactivate parts you don’t use and keep checking vulnerability records. Treat that as a holding position, not a fix. And if a known issue has no patched version, don’t assume a quiet dashboard means you’re fine.
Replace it without breaking the site
This is the bit I wouldn’t rush on a shop with live orders. The replacement may handle the same job while storing its data differently. Test the handover before visitors do it for you.
- Back up the site and make a staging copy. Confirm you can restore the backup before changing the live site.
- Write down what the old plugin owns. Note its settings, shortcodes, blocks and data. Check pages and templates where its output appears.
- Install the replacement on staging. Configure it there, then migrate the data you need. Don’t assume switching plugins moves existing entries.
- Test the real paths. Submit forms, run through checkout if you sell online, and open the pages that use the feature. Try the site as a visitor, not just as an admin.
- Switch on the live site in a quiet hour. Move the tested setup across, deactivate the old plugin, then delete it. Deactivation alone leaves its files on the server.
- Look for leftovers. Check for visible shortcodes, broken blocks and missing data. Watch the error log for the next day or two.
If this is turning into a recurring job across your sites, WordPress maintenance can include these checks and careful replacements. I’d rather schedule a tested swap than discover the problem during a checkout rush.
One thing to check today
Open your Plugins screen and pick three you haven’t seen update in a year. Check their WordPress.org pages, or the vendor changelogs if they’re premium, then search each name in the vulnerability databases. You don’t need to replace all three today. You do need to know which one is waiting for a fix that may never arrive.