WordPress vulnerabilities: find and replace risky plugins

A WordPress vulnerability is almost always in a plugin or theme, not in WordPress itself, so the fix is to find the plugins that are out of date, abandoned or closed on wordpress.org and update or replace them. Patchstack's State of WordPress Security in 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes and six in core. This guide shows how to find the risky ones on your site, how to judge a replacement in ten minutes and how to swap one plugin for another without losing data. It is one part of the WordPress security checklist; plan an hour per plugin, most of it on staging.

Quick answer

• Update first. Most published plugin vulnerabilities are fixed in a newer version. Update core, plugins and themes, then check what is left.
• Closed on wordpress.org: replace it now. The directory closes plugins for unfixed security issues, guideline violations or at the author's request, and no update will ever arrive through wp-admin.
• No release in over 2 years: replace it soon, unless it is tiny and you have read the code.
• Match versions against a vulnerability database (Wordfence, Patchstack and WPScan publish free ones) or let your host's or security plugin's scanner do it.
• Judge a replacement by its wordpress.org page: updated within months, tested with the current WordPress, thousands of active installs, answered support threads.
• Swap on staging, delete the old plugin's folder, then re-run the WordPress health check.

Where WordPress vulnerabilities come from

Core WordPress has a security team, installs minor and security releases automatically by default, and very rarely has a serious hole. Plugins are different: tens of thousands of them, written by authors ranging from large companies to one person who moved on years ago. The common bug types are cross-site scripting, missing permission checks, SQL injection and unrestricted file upload. The last two can hand an attacker the whole site.

The timeline explains the risk. A researcher reports a hole, the author ships a fix, and the vulnerability is published with the affected versions. From that day, scanners look for the plugin's asset paths on every site they can reach. A site that updates within days is fine. A site that runs the old version, or a plugin whose author never shipped the fix, is on the target list.

Abandoned plugins add a second cost. PHP removes functions with each release and WordPress changes its APIs. A plugin last touched in 2022 was tested on PHP 7.4 and WordPress 6.0; on PHP 8.3 it throws deprecation warnings, and on 8.4 it may throw fatal errors that take the whole site down on the day the host upgrades PHP.

Closed plugins are the sharpest case. When wordpress.org closes a plugin it disappears from search, and its page says "This plugin has been closed as of …" with a reason. Every site that installed it keeps running it, the update check returns nothing, and wp-admin shows no warning.

How getReport checks it

The report recognises plugins from what the page reveals: asset URLs under /wp-content/plugins/<slug>/ and the comments some plugins print. It never guesses slugs or probes for plugin folders. Each detected slug is looked up in the wordpress.org plugin directory (cached for a day, up to 25 plugins per report) for the plugin's name, latest version, last-updated date, active installs and, if it was closed, the reason. Two findings come from that lookup:

"Over 2 years" is measured from the directory's last-updated date to the day of the report: 23 months passes, 25 warns. Closed plugins are left out of the abandoned count because they already fail the more serious closed check. Core gets its own finding, read from the generator tag:

The WordPress theme and plugin detector puts it all in one table: every detected plugin with the version its assets carry, the latest version beside it when they differ, its weight on the page and its wordpress.org status.

What the report does not do: it does not match plugin versions against a vulnerability database, and it does not scan the files on your server. Premium and custom plugins are not in the directory, so they show "not in directory" with no dates, which means no data, not a warning. Plugins that work only in wp-admin leave no trace on the page. Step 2 covers those gaps.

Step by step

1. Update what can be updated

Take a backup (see WordPress backups you have test-restored), then Dashboard → Updates. Update core, then plugins, then themes, and click through the pages that matter. On a shop, do it on staging first. Most plugin vulnerabilities are fixed in a release that already exists; updating closes them in minutes.

2. Check the rest against a vulnerability database

With everything current, look for what an update cannot fix: holes the author never patched.

• Free databases. Wordfence Intelligence, Patchstack and WPScan each publish a searchable database of WordPress vulnerabilities with affected and fixed versions. Search each plugin name from Plugins → Installed Plugins.
• Automatic scanning. Security plugins (Wordfence, Patchstack, Solid Security) and many managed hosts compare your installed versions with these databases and email you when one is affected. They see premium and admin-only plugins too, which an outside check cannot. The WordPress security plugins guide compares what each adds.

A vulnerability listed as "no known fix" or "unpatched" means the same as a closed plugin: deactivate it today and replace it.

3. Read the closure reason on wordpress.org

For a closed plugin, open https://wordpress.org/plugins/<slug>/. The banner names the reason:

• Security Issue: a vulnerability was reported and not fixed. Treat the plugin as exploitable today.
• Guideline Violation: the author broke the directory rules (tracking, licensing, trademark). Not necessarily insecure, but there will be no updates.
• Author Request: the author gave up. Same outcome: no updates.

Closed plugins sometimes reopen once the author fixes the issue; the page says so.

4. Decide whether the plugin still earns its place

Plugins accumulate: the gallery from the old theme, share buttons nobody clicks, a TinyMCE add-on that predates the block editor. Open the page where the plugin does its job. If you cannot find it, deactivate the plugin on staging and look for what breaks. A plugin that does nothing visible is replaced by nothing.

5. Judge a replacement in ten minutes

The wordpress.org plugin page has what you need:

Then install it on staging and run the plugin detector: a replacement that loads 300 KB on every page is not an upgrade over one that loaded 20 KB.

Most abandoned plugins have a known successor. The core Cover, Gallery and Query Loop blocks replace most old sliders, galleries and related-posts plugins. Contact Form 7, WPForms, Fluent Forms and Formidable are maintained form plugins. Advanced Editor Tools is the maintained successor of TinyMCE Advanced. Premium themes often bundle old slider and builder plugins that stop updating when the theme does; look those up on the vendor's site.

6. Swap it on staging first

1. Make a staging copy and keep it out of Google, as in the WordPress staging guide.
2. Export what the old plugin owns: form entries, slider configurations, settings. If there is no export, screenshot the settings.
3. Install and configure the new plugin, and import where it offers to (form plugins usually import from each other).
4. Replace the old shortcodes and blocks in content. Search for them ([rev_slider, [contact-form-7) with a search-replace tool.
5. Deactivate the old plugin and click through the pages that used it, logged out, on a phone.
6. Repeat on the live site, or push staging to live if nothing else changed.
7. Delete the old plugin's folder. A deactivated plugin is still code on the server, and a vulnerable file in it can be requested directly.

For a plugin closed for a security issue, or with an unpatched vulnerability, do not wait for staging: deactivate it on the live site today and accept the missing feature for a few days.

Platform notes

Premium plugins. Paid plugins update through their own licence servers and are never in the directory. Check the vendor's changelog. An expired licence means no security updates, which makes it an abandoned plugin from the site's point of view.

Managed WordPress hosts. Many run a vulnerability scanner across customer sites, and some patch or disable vulnerable plugins for you. That covers known holes, not abandonment; the report's two-year check catches the plugins nobody has reported yet.

Multisite. A network-activated plugin is vulnerable on every site at once. Replace it once on a single site, then roll it out.

Verify

• Re-run the WordPress health check. The closed finding reads "No detected plugin has been closed on wordpress.org" and the abandoned finding "Every detected plugin has a recent update".
• The plugin table shows no version behind the latest, and no longer lists the old slug. If it still does, a page references its assets; search the content for the shortcode.
• Your security plugin or host scanner shows no known vulnerabilities, and ls wp-content/plugins/ no longer shows the old folder.

Common mistakes

• Deactivating a vulnerable plugin and stopping there. The files are still on the server, and a scanner does not care whether the plugin is active. Delete it.
• Replacing an abandoned plugin with a fork of itself. Someone re-uploaded the same code under a new name, with one release and no history. Judge the successor by the same table.
• Trusting the version on the page. The ?ver= on an asset URL is what the plugin says, and some print the WordPress version instead. Check Plugins → Installed Plugins.
• Ignoring plugins the theme bundled. They update only when the theme does, and many themes stopped updating years ago.
• Downloading "free" premium plugins. Nulled copies from unofficial sites very often carry a backdoor. That is a vulnerability you installed yourself.

Questions people ask

What is a WordPress vulnerability?

It is a bug in WordPress core, a plugin or a theme that lets someone do what they should not: run scripts in visitors' browsers, read the database, upload files or take over an account. Almost all of them are in plugins. Each is published with the affected and fixed versions, so updating to the fixed version, or replacing a plugin that has none, closes it.

How do I find vulnerable plugins on my WordPress site?

Compare your installed plugin versions with a vulnerability database. A security plugin such as Wordfence or Patchstack, or your host's scanner, does this automatically and sees every plugin, including premium ones. By hand, search each plugin name in the Wordfence, Patchstack or WPScan database. The getReport health check adds the closed and abandoned plugins the page reveals.

Is WordPress core itself vulnerable?

Rarely. Patchstack counted six core vulnerabilities in 2025, all rated low risk, against thousands in plugins. WordPress installs minor and security releases automatically by default, so core is usually patched within a day of a fix. The real risk is a site where automatic updates were switched off or core is several major versions behind.

What if a closed plugin has no replacement?

Deactivate it anyway if it was closed for a security issue, and look at what the feature really needs. Often a core block, a few lines of theme code or a general-purpose plugin covers it. If the plugin is essential and small, a developer can review the code, fix the hole and maintain a private copy, which then becomes your responsibility to update.