CVSS 9.8 does not mean you are 9.8 in trouble
A CVSS score measures severity, not risk. The standard's own user guide says the base score should not be used alone to assess risk, because it covers only the intrinsic qualities of a flaw and assumes the reasonable worst case across every deployment. Three questions turn a sorted list into your priority order.
- FIRST, which publishes the standard, states plainly that base scores are not risk and should not be used alone for patch prioritization.
- The base score assumes the reasonable worst case across every deployment, with your firewall and segmentation assumed away on purpose.
- Two of the metric groups describe your business, and the standard says filling them in is the buyer's job, not the scanner's.
- Read the vector string. All base metrics are mandatory in it, while the environmental ones are optional and default to Not Defined.
- Exploitation, exposure and business importance reorder a list better than severity does. CISA sets its own deadlines from four variables, and severity is only one.
What does a CVSS score actually measure?
A CVSS score measures how severe a software flaw is, not how much trouble your business is in. The group that publishes the standard says so outright. Its current FAQ states that CVSS-B Base scores are not risk, and should not be used alone for patch prioritization.
CVSS stands for Common Vulnerability Scoring System. It is a free, published, open standard, maintained by FIRST, the Forum of Incident Response and Security Teams. Your vulnerability scanner did not invent that number. It read a specification, and the specification is unusually clear. The v3.1 user guide titles one section CVSS Measures Severity, not Risk, then spells it out. CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk, and a full risk assessment also weighs factors outside the scope of CVSS such as exposure and threat.
That is the inversion. Every scanner vendor publishes a guide to reading the score. The people who write the score say not to read it alone. Read this beside our guide to your patch compliance rate, which covers the other half of the same monthly report.
The severity rating scale itself is short and public. None sits at 0.0, Low at 0.1 to 3.9, Medium at 4.0 to 6.9, High at 7.0 to 8.9 and Critical at 9.0 to 10.0. A 9.8 sits near the top of the Critical band. The specification then adds a line almost no report mentions. The use of these qualitative severity ratings is optional.
So Critical is a label somebody chose to attach to a number, on a scale the standard itself calls optional. A scanner ranks findings by severity because severity is the only thing it can see.
The base score is written for the worst version of your business
The base score is deliberately written for the worst case, because one number has to serve every organization that runs the same software. The specification states the design goal directly. A base score assumes the reasonable worst case impact across different deployed environments and represents the intrinsic characteristics of a vulnerability that are constant over time and across user environments.
Hold on to the phrase constant across user environments. The number cannot move for you, because it was built not to.
The scoring rules go further than most buyers expect. When an analyst scores the exploitability half of a base score, it should be assumed that the attacker has advanced knowledge of the weaknesses of the target system, including general configuration and default defense mechanisms. Your firewall, your rate limits and your network segmentation are assumed away on purpose. The specification says where they belong instead. A target-specific mitigation should instead be reflected in the Environmental metric scoring group.
Put those two rules together and a 9.8 reads differently. It describes the worst plausible deployment of that software anywhere in the world, with your defences switched off and the attacker fully briefed. That is fair for one global number. It is a poor way to decide what your two technicians do on Monday.
A base score tells you how bad the flaw is in the worst house on the street. It does not tell you whether you live there.
None of this makes the flaw harmless. Verizon's 2026 breach report found exploitation of vulnerabilities is now the most common initial access vector, at 31 percent of breaches, while credential abuse fell to 13 percent. Unpatched software is now the single most common way in, so patch management matters more than it did two years ago. Sorting by the wrong column simply means you patch the wrong thing first.
The part of the standard that describes your business is the part nobody fills in
CVSS has more than one scoring group, and the groups that describe your business are optional additions almost nobody completes. In CVSS v4.0 the groups are Base, Threat, Environmental and Supplemental.
The threat metrics cover what has changed since the flaw was published. That group reflects the characteristics of a vulnerability related to threat that may change over time, such as whether working exploit code is circulating. The environmental metrics cover you. That group represents the characteristics of a vulnerability that are relevant and unique to a particular consumers' environment, and the specification names the presence of security controls which may mitigate some or all consequences of an attack among the things it accounts for. A compensating control you already pay for belongs there and nowhere else.
Then the standard says whose job it is. The application of Environmental and Threat metrics is the responsibility of the CVSS consumer. The consumer is you, or the provider you pay to do this for you. The same page is equally clear about what suppliers hand over. Assessment providers such as product maintainers and other public/private entities such as the National Vulnerability Database (NVD) typically provide only the Base Scores enumerated as CVSS-B. The v4.0 FAQ repeats the division of labour, stating that consumers should also be the only ones in the vulnerability assessment process to apply Environmental metrics.
So your report arrives with the contextual half of the standard blank, and the standard expects somebody on your side to fill it in. Ask your provider who did.
How to check in ten seconds, using the vector string
To check whether anyone applied your context, read the vector string next to the score. A vector string is a text representation of a set of CVSS metrics, the short code recording every metric value behind the number. FIRST says anyone publishing CVSS data should supply both the score and the vector string so others can understand how the score was derived.
The mechanics settle the argument. All Base metrics must be included in a vector string, while the threat, environmental and supplemental metrics are optional, and anything left out is treated as Not Defined. Read that twice. The half of the standard that measures the flaw is mandatory. The half that measures your exposure to it is optional and defaults to absent.
CVSS v4.0 added a plain-English label for the same reason. CVSS-B means base metrics only, CVSS-BT adds threat, CVSS-BE adds environmental, and CVSS-BTE uses all three, and the specification says this nomenclature should be used wherever a numerical CVSS value is displayed or communicated. That gives you a one-line test. Find the label, and if every row reads CVSS-B, nobody has looked at your environment yet.
What the environmental metrics would actually change
The standard publishes a worked example of context moving a number. In the v3.1 user guide, a stored SQL injection flaw in MySQL carries a base score of 6.4. Where the analyst has high confidence that the vulnerable component is deployed on a secure network unreachable from the internet, the modified attack vector is set to Adjacent and the environmental score falls to 5.4. One flaw, two numbers, and the difference is the network it sits on.
The v4.0 environmental group gives you fourteen dials. Eleven restate a base metric for your deployment, including modified attack vector and modified privileges required. The other three are the Security Requirements, and they are the only part of CVSS a non-technical owner can answer alone. Confidentiality Requirement, Integrity Requirement and Availability Requirement enable the consumer to customize the assessment depending on the importance of the affected IT asset, so that the analyst can assign a greater value to Availability metrics relative to Confidentiality and Integrity.
That is a business question wearing technical clothes. A dental practice cares most about confidentiality, because patient records carry the legal exposure. A machine shop cares most about availability, because an idle line costs money by the hour. Nobody at a scanner vendor knows which one you are.
Which CVSS version is your report using?
Ask which version produced each score, because v3.1 and v4.0 name their parts differently and calculate the number differently. Both are still in circulation, and one monthly report can carry rows from each.
In CVSS v3.1 the three groups are Base, Temporal and Environmental. In v4.0 the Temporal group was renamed Threat, and a fourth group, Supplemental, was added. The severity bands did not move, and Critical still runs from 9.0 to 10.0 in both versions. The arithmetic did move. FIRST states that the method for determining the numeric score is new in CVSS v4.0 and that Attack Complexity was split into Attack Complexity and Attack Requirements.
The consequence is practical. The same flaw can carry two different numbers under the two versions, so a 9.8 in one is not a 9.8 in the other. If your report mixes both, part of the sort order is an artefact of which version each row was scored under rather than a judgement about your business.
One more v4.0 quirk is worth a line. The supplemental group adds six optional descriptors, including Safety, Automatable and Recovery, and the specification states that no metric will have any impact on the final calculated CVSS score. Automatable tells a buyer whether an attacker can script the attack at scale, and it changes nothing about the number printed beside it.
Question 1. Is anyone actually exploiting it?
To turn a severity list into a priority list, start with exploitation. A flaw nobody has ever used is a different problem from one being used this week, and the base score cannot tell them apart. Two free, public sources can.
The first is the CISA Known Exploited Vulnerabilities catalogue. CISA calls it the authoritative source of vulnerabilities that have been exploited in the wild, and it held 1,754 entries when we read it on October 21, 2026. The required action on each entry is to apply mitigations in accordance with vendor instructions, and CISA asks organizations to use the KEV catalog as an input to their vulnerability management prioritization framework. A KEV listing is not a forecast. It records that somebody has already been attacked this way.
The second is EPSS, the Exploit Prediction Scoring System, published by the same body that publishes CVSS. EPSS estimates the probability a vulnerability will be exploited in the wild within the next 30 days, produces a score between 0 and 1 for every publicly disclosed vulnerability, and is updated daily. It is free, and most scanner vendors can already display it. The scale is calibrated, so the number means something concrete. FIRST explains that a score of 0.05 should correspond to a 5 percent empirical exploitation rate over 30 days.
The two numbers do not measure the same thing, and FIRST is blunt about that. CVSS and EPSS measure different things and are empirically uncorrelated. A severe flaw with a low exploit probability is not a contradiction, and FIRST says both assessments can be correct simultaneously. EPSS does read the CVSS metrics, because it uses all individual CVSS metrics as input features while ignoring the scores themselves.
The scale of the gap should change how you read a report. FIRST states that in any given 30 day period, we are tracking anywhere from 1.5% to 3% of published vulnerabilities with exploitation activity, which is where its base rate of around 2 percent comes from, and the Why EPSS page puts the fraction of known vulnerabilities exploited in any 30-day window in the low single-digit percent. The median EPSS score is around 0.7 percent. FIRST also publishes an effort equivalence, with the caveat that it is not an endorsement of the underlying CVSS categories. Chasing every Critical finding costs about the effort of working down to the EPSS 90th percentile, a 4 percent probability of exploitation.
One honest gap is worth stating. We found no primary source reporting what share of Critical-rated flaws are ever exploited, so treat any such figure you are quoted as unverified until the vendor names the study. The base rates above cover all known vulnerabilities, not the high-scoring ones.
FIRST also names the mistake vendors make with these two numbers. Do not multiply an EPSS score by an ordinal (such as CVSS) and think that produces a combined risk score. FIRST calls that score laundering. If your provider's dashboard shows one blended risk figure per finding, ask how it is calculated before you sort by it. For a catalogued flaw, FIRST gives the simple rule. Treat it as actively exploited and prioritize accordingly, regardless of EPSS score.
EPSS has a boundary you cover yourself. FIRST says it has no visibility into your asset inventory or compensating controls, and that EPSS does not measure how much damage successful exploitation would cause. Those omissions are question two and question three.
Question 2. Can an attacker reach the machine at all?
Ask whether the affected machine can be reached from the internet, because exposure decides the deadline in the one place this question has been settled in public. CISA now runs federal patching this way, and the directive is free to read.
Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, issued on June 10, 2026, sets each remediation deadline from four variables rather than a severity rating. The four are asset exposure, whether the CVE sits in the KEV catalogue, whether an adversary is able to automate all the steps necessary to exploit the vulnerability, and whether the adversary gains partial or total control of the asset.
Notice where CVSS appears in that list. CISA borrows the base score idea for exactly one of the four, describing technical impact as similar to the Common Vulnerability Scoring System (CVSS) base score's concept of severity. The other three are about the machine and the attacker. The directive's stated aim is to focus patching efforts on the areas of highest risk rather than treating all vulnerabilities and systems equally.
The spread of deadlines shows what that buys. The worst combination carries a three-day deadline plus a forensic triage of the asset. The mildest is fix on system upgrade, meaning the next scheduled rebuild. One severity rating can fall into either bucket, and what decides it is where the asset sits.
The effect is to lift an exploitable flaw on an exposed box above a severe flaw nobody outside can reach. You are not a federal agency, and the yardstick still works, because all four questions are about your estate. Our network vulnerability assessment checklist walks the scoping step that produces the exposure answer, and the devices most often missing from it are covered in the firmware updates nobody covers.
Question 3. What does the machine do for the business?
Ask what the affected machine does for the business, because that is the one input only you can supply. A scanner sees an operating system. It cannot see that one server runs payroll and the other runs a retired reporting tool.
CVSS has a field for it, in the Security Requirements metrics above. CISA asks the same question in plainer words, through a method it uses instead of a single score. SSVC, Stakeholder-Specific Vulnerability Categorization, is a vulnerability prioritization methodology that helps an analyst decide on vulnerability response actions. It is a decision tree, not a number, and five decision points feed it. Exploitation status, technical impact, automatable, mission prevalence and public well-being impact.
Mission prevalence is the business question. How much of the work stops if this asset stops. Put that beside exploitation status and you have reproduced most of what a paid risk-scoring product sells.
The tree produces four decisions rather than a ranked list. Track means the vulnerability does not require action at this time, remediated within standard update timelines. Track with an asterisk means the same, with closer monitoring. Attend requires attention from the organization's internal, supervisory-level individuals and is remediated sooner than standard timelines. Act requires attention from supervisory and leadership-level staff and remediation as soon as possible.
Four decisions beat a hundred-row sorted list, because a list contains no decisions. Note what the method does not produce. It gives you no number at all.
This is also where a 9.8 can honestly be left alone. A severe flaw on an isolated test machine holding no business data is a legitimate exception, provided a named person writes it down with an expiry date. That record has a proper shape, set out in our guide to the exception register. An undated verbal decision is not an exception. It is a forgotten risk with nobody's name on it.
Where the honest answer is that no fix exists, the problem has left scoring and become a replacement budget. That case is covered in end-of-life software risk.
What to ask your provider on Tuesday
Send your provider seven questions in one email, then judge the reply by how long it takes. Each answer sits in a tool they already run, so a provider who operates vulnerability management replies in a day. A provider who only resells the scanner offers a meeting, and the delay is the finding.
- Ask which CVSS version produced each row of last month's report, and whether both versions appear in one file.
- Ask whether any row carries threat or environmental metrics, or whether every score is a bare CVSS-B.
- Ask for the vector string beside each finding, so you can verify which metrics were left Not Defined.
- Ask for the subset of findings that appear in the CISA KEV catalogue, as a separate short list.
- Ask for the EPSS exploit probability against each finding, since it is published daily and costs nothing.
- Ask which affected assets are internet-facing, because that split sets the real remediation deadline.
- Ask who set the confidentiality, integrity and availability weighting for your business, and when.
Then change two lines in the agreement rather than the proposal deck. Name the sort order in the service level agreement, so deadlines follow exposure and exploitation rather than the raw score, and so the rule survives a change of technician. And require that any finding left open past its deadline lands on the exception register with a named owner and an expiry date.
The arithmetic favours doing this. Verizon found only 26 percent of critical vulnerabilities in the CISA catalogue were fully remediated in 2025, down from 38 percent, at a median 43 days to fully resolve one. Those are flaws confirmed as being used in attacks, and roughly three quarters stayed open while the monthly reports kept arriving.
None of this buys perfect security, and no honest provider offers it. It buys a measurable priority order you can defend, assembled from published standards and an independent reading of your own estate rather than from a column somebody sorted. For the wider version of the exercise, work through our cybersecurity risk assessment checklist, and for what each kind of test contributes, read vulnerability assessment vs penetration testing.
FAQ
What does a CVSS score of 9.8 mean?
A 9.8 sits in the Critical band, which the standard sets at 9.0 to 10.0. It means the flaw is severe in the worst plausible deployment, assessed with your own defences assumed away. FIRST states that base scores are not risk, and should not be used alone for patch prioritization.
Is a CVSS score the same as risk?
No. The standard's own user guide states that CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk. A base score covers only the intrinsic characteristics of a vulnerability which are constant over time and across user environments. Risk needs exploitation data and your own asset context on top.
What is the difference between CVSS and EPSS?
CVSS rates how severe a flaw is. EPSS estimates the probability a vulnerability will be exploited in the wild within the next 30 days, on a 0 to 1 scale updated daily. FIRST says the two are empirically uncorrelated and warns that multiplying EPSS by a CVSS score does not compute probability times severity.
Should I patch every CVSS Critical vulnerability first?
Not automatically. CISA sets its own federal deadlines from four variables, and the base score idea covers only one, described as similar to the CVSS base score's concept of severity. A Critical finding on an isolated internal machine can wait behind a High finding on an internet-facing firewall listed in the KEV catalog.
Which CVSS version should my vulnerability report use?
Ask, because both are in circulation. Version 3.1 names its groups Base, Temporal and Environmental, while v4.0 renames Temporal to Threat and adds Supplemental. FIRST says the method for determining the numeric score is new in CVSS v4.0, so the same flaw can carry different numbers under each version.
Best IT MSP is the independent directory of vetted managed IT and cybersecurity providers across North America. Organic ranking is earned on rating and verified data, and paid placement is always labelled. Take these seven questions to three merit-ranked firms in your city and compare the answers side by side.