You open the WordPress dashboard and a security plugin says one of your plugins has a “known vulnerability”. Or a hosting email says the same thing in more alarming words. It is hard to know how worried to be. Is the site already hacked? Does it need fixing tonight? Is the plugin now unsafe forever?
Usually the answer is calmer than the warning sounds, but the warning is not something to ignore either. This post explains what a plugin vulnerability actually is, how one goes from discovery to a fix, and how to check the plugins on your own site without becoming a security researcher.
What a vulnerability is, in plain words
A plugin is code written by someone else that runs with a lot of trust inside your site. A vulnerability is a mistake in that code that lets someone make it do something it was never meant to do. The mistake is usually small: a missing check on who is allowed to perform an action, a form field whose content is not cleaned before use, or a file upload that does not confirm the file is really an image.
The consequences range widely. Some flaws let a logged-in subscriber see a setting they should not. Others let an anonymous visitor upload a file and run it, which is effectively full control of the site. The plugin’s name in a warning tells you very little. What matters is what the flaw allows and who can trigger it.
The life of a vulnerability
Most plugin flaws follow a similar path. Knowing it helps you read warnings sensibly.
1. Someone finds it
Vulnerabilities are found by independent researchers, security companies, the plugin’s own developers, and sometimes by attackers. Several security firms that focus on WordPress run research teams and bug bounty programmes that pay researchers to report flaws privately rather than sell or publish them.
2. It is reported privately
In responsible disclosure, the finder tells the plugin developer (directly or through a security company acting as go-between) and gives them time to fix it before anything is made public. If the developer does not respond, the WordPress.org plugins team can be contacted, and they can close a plugin in the directory until the issue is dealt with.
3. A fix is released
The developer releases an update. A good changelog will mention a “security fix” even if it does not give details, because detailed descriptions help attackers who have not found the flaw yet.
4. It is published
After the fix is out, the vulnerability is added to public databases, often with an identifier (a CVE number) and a severity score. This is the moment many sites start getting warnings, because security plugins and scanners check installed versions against these databases.
5. Attackers start scanning
Once details are public, automated tools begin probing sites for the vulnerable version. That is why the gap between publication and your update matters most. A flaw nobody knows about is rarely exploited at scale. A flaw that is public, easy to use and present on many sites gets exploited quickly.
Not every case follows this neat order. Sometimes a flaw is exploited before anyone reports it, and the first sign is sites being hacked. Those are the cases that tend to make security news.
Where vulnerability information comes from
You do not need to read raw security advisories. A few databases collect WordPress plugin and theme vulnerabilities in one place, and most security tools draw from them:
- Wordfence publishes a vulnerability database alongside its security plugin, and the plugin uses that data to warn about vulnerable versions on your site.
- Patchstack runs a vulnerability database and research programme focused on WordPress.
- WPScan maintains a WordPress vulnerability database, used by its own scanner and by other tools.
Each entry usually lists the affected plugin, the vulnerable version range, the version that fixed it (if one exists), the type of flaw and a severity rating. Those are the details you need to make a decision.
How to read a vulnerability entry
When a warning appears, open the entry and look for these fields:
- Affected versions. Compare them with the version installed on your site. If you are already on the fixed version, the warning may be stale.
- Fixed in. Whether an update exists. “No known fix” is a different and more serious situation.
- Who can exploit it. Entries often say “unauthenticated” (anyone on the internet), or name a role such as subscriber, contributor or administrator. Unauthenticated flaws are the urgent ones. A flaw that needs an administrator login is much less of a concern on a site with only trusted admins.
- Type. Phrases like arbitrary file upload, remote code execution, SQL injection, privilege escalation or cross-site scripting. Our post on SQL injection and cross-site scripting in plain language explains two of the most common ones.
- Severity score. Often a CVSS score from 0 to 10, or a label such as low, medium, high or critical. It is a guide, not a verdict, because it cannot know how your site is set up.
Checking the plugins on your site
You can do a useful check in about twenty minutes.
List what you have
Go to Plugins in the dashboard and note every plugin, active and inactive, with its version. If you have WP-CLI access, wp plugin list prints the same information with update status. Do the same for themes, including ones you are not using.
Inactive plugins count. Their files are still on the server, and some flaws can be reached directly through a file in the plugin folder without the plugin being active.
Check for updates and warnings
WordPress shows when an update is available. A security plugin, if you run one, will flag plugins with known vulnerabilities. If you do not run one, search the plugin’s name in one of the databases above and compare the listed versions with yours.
Look at the plugin’s health
For each plugin from the WordPress.org directory, its directory page shows when it was last updated and which WordPress version it was tested with. If a plugin has been closed in the directory, the page says so. A plugin with no updates for a long time is not automatically vulnerable, but it means that if a flaw is found, nobody may fix it. Our post on handling a plugin its developer has left behind covers how to handle those.
Note where plugins came from
Premium plugins bought from a developer’s own site update through their licence system. If the licence has lapsed, the updates stop, even for security fixes. Plugins downloaded from unofficial “free premium” sites are a separate and worse problem, because they can contain malware from the start.
Deciding what to do
Once you have the facts, the decision is usually one of these:
| Situation | Sensible response |
|---|---|
| Fixed version available, flaw is unauthenticated | Update as soon as possible. Check the site for signs of compromise afterwards. |
| Fixed version available, flaw needs a higher role | Update in your next maintenance window, sooner if you allow open registration. |
| No fix, plugin is not essential | Deactivate and delete it, then find a maintained alternative. |
| No fix, plugin is essential | Restrict access to the vulnerable feature, consider firewall rules, and plan a replacement. |
| Plugin inactive and unused | Delete it. There is no reason to keep its files around. |
Updates can occasionally break a site, especially major version jumps. If the site matters to your income, test the update on a copy first. Our guide to using a staging site for WordPress explains how. For a security update to an unauthenticated flaw, though, the risk of waiting is usually larger than the risk of a short breakage.
Was the site exploited before you updated?
Updating closes the hole. It does not remove anything an attacker already put through it. If the vulnerable version sat on your site for a while after the flaw became public, check for:
- Administrator accounts you do not recognise.
- Any .php file sitting inside wp-content/uploads.
- Recently changed files in plugin and theme folders.
- New scheduled tasks, unknown plugins, or changes to the site’s settings.
- Google Search Console messages about security issues.
If any of those turn up, the update was not enough on its own. The site needs cleaning, and the backdoors left behind need finding. A site that keeps being reinfected after an update is often in exactly this position: the door was closed but someone was already inside.
Keeping on top of it
The practical habits are not complicated:
- Keep the number of plugins down. Each one is more code that can have a flaw.
- Delete what you do not use, including old themes.
- Turn on automatic updates for plugins you trust and that rarely cause problems. WordPress lets you do this per plugin from the Plugins screen.
- Run a security plugin or service that checks installed versions against a vulnerability database and tells you when something needs attention.
- Keep premium licences current so security updates keep arriving.
- Check updates weekly, not when you remember. Our comparison of core, plugin and theme updates covers how each type behaves.
If you would rather not track this yourself, it is the core of our ongoing security maintenance: watching for vulnerable versions, updating carefully, and checking afterwards.
If you think a vulnerable plugin has already been used
A warning about a plugin you updated weeks late, combined with anything odd on the site, is worth taking seriously. Our hacked website repair page explains how to reach us urgently and what we do first. We will look at the site and tell you honestly whether it shows signs of compromise or just needs the update you have already made.
Next in this series: SQL Injection and XSS Explained for Website Owners
