Every WordPress site accumulates plugins the way a garage accumulates boxes: installed for one project, never removed, quietly going stale. The problem is that a stale plugin is not a cosmetic issue, it is an open door.
The scale of the problem
Patchstack's State of WordPress Security 2025 report counted 11,334 new vulnerabilities across the WordPress ecosystem that year, and attributed 91% of them to plugins rather than themes or WordPress core. The same report found 46% of those vulnerabilities had no developer patch available at the time they were disclosed.
How WordPress.org flags it
The plugin directory itself warns you, if you know where to look. WordPress.org's own developer documentation describes the exact banner shown on a stale plugin's page: "This plugin hasn't been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress." That banner is a visible signal, not a guess, and it is worth reading before you install anything new too.
Why "it still works" is not good enough
A plugin can keep functioning perfectly on the front end while its unpatched code sits exposed on the back end. Attackers scan for exactly this: outdated plugin signatures that match a known, public vulnerability.
A 20-minute audit
- Go to Plugins in your dashboard and sort by "last updated".
- Anything untouched for over a year gets a hard look: is it still needed, and is there an actively maintained alternative?
- Remove plugins you are not using, rather than just deactivating them. A deactivated plugin's code is still sitting on the server.
AuditMerlin will not list which specific plugins are outdated, but it does check the WordPress fingerprinting issues that make a site easier to target in the first place, version disclosure and xmlrpc.php exposure among them. A free scan is a reasonable second step after you have cleared out the dashboard.