A plugin vulnerability alert lands in your inbox with a scary severity label and a CVE number, and the instinct is to drop everything and patch across all 80 sites before lunch. Sometimes that is exactly right. Often it is not, and the difference is a handful of questions you can answer in a couple of minutes per advisory.
Treating every CVE as an emergency has a cost of its own: rushed updates break sites, you burn goodwill with clients over false alarms, and the truly dangerous alert gets the same reaction as the trivial ones.
Why the headline severity is a bad guide
A CVE entry describes a flaw in a piece of software. The severity rating attached to it describes how bad the flaw could be under generic assumptions. It does not know your site.
Two examples of how far the label and the reality can drift apart. A high-severity flaw that requires an administrator login to exploit matters far less on a site with two trusted admins and two-factor authentication than on a site with open registration. And a medium-severity flaw that lets an unauthenticated visitor read files can be a genuine emergency if the file in question is wp-config.php.
The rating is where triage starts. It is not where it ends.
Five questions that decide the response
Run each advisory through the same short list.
- Is the vulnerable plugin actually installed and active? Deactivated plugins can still be exploited in some cases, since their files are on disk, but an uninstalled one is not a risk at all. Check installed, not just active.
- Is your version in the affected range? Advisories list the versions affected and the version that fixes them. Many alerts do not apply because the site is already patched.
- What does an attacker need first? Nothing (unauthenticated), a subscriber account, an editor account, or an administrator. The lower the bar, the more urgent.
- What can they do with it? Read data, change content, run code, or take over the site. Code execution and account takeover sit at the top.
- Is there a known exploit in use? Public advisories usually say whether exploitation has been observed. Active exploitation moves an issue from "soon" to "now".
Answer these and most advisories sort themselves. A flaw needing admin access, with no known exploit, in a plugin that is present on three sites, is a scheduled update. An unauthenticated code-execution flaw under active attack in a plugin installed on forty of your sites is a stop-what-you-are-doing situation.
Turn the answers into three lanes
Once you have answers, you need a response that does not depend on your mood.
| Lane | Conditions | Target | |---|---|---| | Emergency | Unauthenticated or low-privilege, serious impact, exploitation seen | Patch or mitigate the same day | | Soon | Serious impact but a real precondition, or no known exploit | Patch within the week, with normal testing | | Routine | Needs admin access or has minor impact | Next scheduled update cycle |
Write these targets down and send them to clients as part of the care plan. A stated policy reads as competence. An improvised one reads as panic.
The same flaw matters differently on different sites. A store holding customer data and taking payments sits above a five-page brochure site with no user accounts. A membership site with open registration sits above a site where only staff can log in.
Sort your portfolio into rough tiers before an alert arrives. When one does, you already know which sites go first. If the triage of an advisory takes five minutes and you have 60 sites, sorting by exposure is what stops it becoming five hours.
Emergency does not mean reckless
Even in the emergency lane, the update itself carries risk, and pushing it blind onto every site is how you swap one problem for another. Take a restore point first, apply the update, and compare the site visually before and after. We cover the mechanics in safe WordPress updates, explained.
If a patch does not exist yet, you have other options that buy time:
- Deactivate and remove the plugin if the site can live without it.
- Block the vulnerable endpoint at the firewall or with a server rule, when the advisory names it.
- Restrict access to the affected area, for example limiting a vulnerable admin screen by IP.
Note what you did and set a reminder to remove the mitigation once the fix ships. Temporary rules become permanent by neglect.
What to tell clients, and when
Most clients do not need to hear about every advisory. They need to hear when something affected them and that it was handled.
For routine and soon-lane items, mention it in the monthly report: "A vulnerability was disclosed in one of your plugins; we patched it within four days." For emergency items, a short direct message is right: what the issue was, whether there is any sign the site was affected, and what you did. Skip the jargon and skip the alarm. "We patched a flaw in your contact form plugin the day it was disclosed, and found no sign it was abused" is a complete and reassuring message.
If you do find signs of compromise, that is a different process: contain, restore from a clean backup, rotate credentials, and investigate. Keep that separate from vulnerability triage, because it is a different problem with different urgency.
Tooling that does the sorting
The work above is mostly matching: which plugins, which versions, which sites. That is what software is good at. WPClientHub scans your sites against known vulnerabilities and explains each finding in plain English, including what an attacker would need and what the fix is, so you can place it in a lane quickly and forward the explanation to a client without rewriting it. It answers the first two questions for you; the last three still take judgment, and they should.
Whatever tool you use, check that it tells you which site is affected and which version fixes it. An alert that only says "vulnerability detected" gives you no help with triage.
Where this leaves you
A CVE is a reason to ask five questions, not a reason to panic. Set three lanes with written targets, tier your sites by exposure in advance, and reserve same-day patching for the flaws that are easy to exploit and serious in effect. WPClientHub is free for 3 sites if you want to see vulnerability findings on a real client site.