In early August a PHP object injection flaw in a WordPress search plugin was published with a CVSS score of 9.8. Two days later a cross site scripting issue on the WordPress login screen arrived at 8.9. Both are serious. They are not equally urgent for your site, and the scores do not tell you which is which.
Anyone maintaining more than a couple of sites needs a way to triage, because 250 plugin vulnerabilities are disclosed weekly and patching everything the same afternoon is not a plan. Understanding what the number measures is most of that skill.
What the score actually describes
CVSS rates the flaw in isolation, on a scale to 10, assembled from a handful of inputs. Can it be exploited over the network or does it need local access. How complex is the attack. Does it require an account, and if so what kind. Does it need someone to click something. What does it compromise if it works.
A 9.8 typically means network reachable, low complexity, no authentication, no user interaction, and complete compromise of confidentiality, integrity and availability. That combination is genuinely alarming, and it is a description of the vulnerability rather than of your situation.
The score deliberately excludes everything about you. It does not know whether you run the affected plugin, whether the vulnerable feature is enabled, what version you are on, or whether your site holds customer records or a menu of opening hours. Those are the facts that determine your risk, and none of them are in the number.
Object injection, in plain terms
The 9.8 in question was PHP object injection, which sounds abstract and is worth understanding because it recurs.
PHP can turn an object into a string for storage and turn it back later. If an application does that second step on data supplied by a visitor, the visitor gets to decide which class is reconstructed and what values it holds. That alone does nothing. The damage comes when the reconstructed object has methods that run automatically and do something useful to an attacker, like writing a file or executing a command.
Whether that second condition exists depends on what else is installed. The same flaw on two sites can mean nothing on one and complete compromise on the other, purely because of which other plugins are present and what classes they define.
That is exactly the kind of thing a single number cannot capture, and it explains why two sites with identical scores face different actual risk.
Three questions that beat the score
Do you run the affected component, at an affected version. A surprising amount of patching anxiety dissolves here. Maintain a current list of what is installed where and this takes minutes rather than an afternoon of checking sites individually.
Is the vulnerable path reachable on your configuration. Many flaws require a feature to be enabled, a setting to be non default, or a particular integration to be present. Advisories usually say. Reading the advisory rather than the headline is the single highest value habit in this work.
What would an attacker get. A vulnerability that exposes a plugin's own settings on a brochure site is different from the same class of flaw on a site holding customer orders. The score is identical; the consequence is not.
Answer those three and you can order a week of patching sensibly rather than treating every advisory as an emergency or, more commonly, treating none of them as one.
We use exactly these three when a client forwards an advisory in a panic, and they usually settle it within minutes. Most high scores turn out not to apply to how the plugin is configured on that particular site.
Where scores mislead in both directions
High scores that are not urgent for you are the obvious case. A 9.8 in a plugin you removed last year is a headline and not a task.
The more dangerous error is the opposite. A medium score on something with a specific property can matter more than a high score without it. Anything unauthenticated deserves attention regardless of its number, because the attacker pool is everyone rather than everyone with an account. Anything in a component with millions of installs deserves attention because automated scanning becomes economically worthwhile at that scale.
A 6.5 that needs no credentials, in a plugin on seven million sites, will be exploited at scale within days. A 9.1 requiring administrator access is a serious flaw that an attacker with administrator access barely needs. The numbers rank those the wrong way round for practical purposes.
Build the list before you need it
Everything above depends on knowing what you run, and most people responsible for several sites do not have that written down anywhere.
An inventory of sites, plugins, versions and hosting is not sophisticated and it converts every future advisory from an investigation into a lookup. It also surfaces the abandoned plugins nobody remembers installing, which is where the real exposure usually sits. We covered building that properly in auditing what you have installed.
Alongside it, subscribe to a vulnerability feed that covers the plugin ecosystem rather than relying on your dashboard to tell you. The dashboard tells you an update exists. It does not tell you the update is a security fix that is already being exploited.
The sites that handle disclosure badly are not the ones with the most vulnerabilities. They are the ones where nobody can say what is installed, and we find that more often than we find the vulnerability.
What actually needs to happen the same day
Unauthenticated, remotely exploitable, in something you definitely run, with a public advisory: patch today, out of hours if necessary. Modern WordPress vulnerabilities are exploited within hours of disclosure because the target list is trivial to build.
Everything else can join a weekly cycle, which is a realistic cadence for most teams and considerably better than the monthly window many sites actually operate on.
If you cannot patch immediately, reduce exposure rather than doing nothing. Disable the affected feature, restrict access at the firewall, or take the component out entirely if it is not load bearing. Partial mitigation today beats a perfect fix on Friday.
A high score you cannot patch safely is a different problem again, and that is what happens when the update channel itself is compromised, covered in when the update is the attack.
If you look after client sites and this is currently reactive, our WordPress development team runs it as a maintained inventory with a patch cycle, which is the only version that works at more than a handful of sites.
Frequently Asked Questions
Should I patch everything scoring above 9?
Patch everything eventually. Order by whether it is unauthenticated, whether you actually run it, and what an attacker would reach. A 9.8 in a plugin you do not have is not a task. A 6.5 that needs no login in something on every one of your sites is.
Why do two sources give different scores for the same flaw?
CVSS has several components and vendors sometimes assess them differently, particularly scope and impact. The base score is also modified by temporal and environmental factors that most published figures omit. Treat the number as an indicator rather than a measurement.
What does unauthenticated actually mean in practice?
Anyone who can reach your site can attempt it, with no account and no credentials. That is the property that turns a vulnerability into mass exploitation, because attackers can scan the whole web for it cheaply. If an advisory says unauthenticated, move it up your list whatever the number says.
Is a high score always worse than a medium one?
No, and assuming so is the most common triage mistake. Reachability and install base often matter more than the score. A widely installed plugin with a medium unauthenticated flaw will see far more exploitation than a rare plugin with a critical one requiring admin rights.
How do I know if I am running an affected version?
From an inventory you maintain, not by checking each site when news arrives. Without one you are doing an investigation every time an advisory lands, which is why most people give up and hope. The inventory is the thing that makes triage possible at all.
What if the developer has not released a fix yet?
Reduce exposure while you wait. Disable the feature, restrict the endpoint, add a firewall rule for the known pattern, or remove the plugin if you can live without it. Unpatched and unmitigated is a choice, and it is the wrong one when the flaw is already public.
Do these scores apply outside WordPress?
Yes, CVSS is used across the industry, and the reasoning here transfers directly to any dependency you rely on. The WordPress ecosystem simply produces a high volume of public advisories, which makes it the place most people first need a triage method.
Talk to our team if you look after several sites and want patching run on an inventory rather than on headlines.