If you have ever opened a vulnerability report and seen a number like 9.8 next to a finding, you have already met CVSS. The number looks precise. It feels authoritative. Yet most people who triage vulnerabilities every day cannot say exactly what that number measures, where it comes from, or what it deliberately leaves out.
This guide answers the question directly. It explains what a CVSS score is, what the digits actually represent, how to read the string of letters that travels with the score, and how to use the rating without trusting it more than it deserves. The goal is a working mental model you can apply the next time a scanner hands you a list of findings.
This is a definition-first explainer. If you want the hands-on mechanics of reading CVSS, CWE and CVE together inside a vulnerability template library, that practical walkthrough lives in our companion piece on reading CVSS, CWE and CVE in a template library. Here we stay on the standard itself.
What CVSS Is and Who Maintains It
CVSS stands for the Common Vulnerability Scoring System. It is an open framework for communicating the severity of a software vulnerability as a single number between 0.0 and 10.0, along with a structured description of how that number was reached.
CVSS is maintained by FIRST, the Forum of Incident Response and Security Teams. FIRST publishes the specification, the metric definitions, and the formulas that turn a set of inputs into a score. Because the standard is public and the math is fixed, two people who score the same vulnerability with the same inputs should arrive at the same number. That repeatability is the whole point. CVSS exists so that a vulnerability rated by a scanner vendor, a software publisher, and a national database can be compared on the same scale.
It helps to be clear about what CVSS is not. It is not a list of vulnerabilities. It is not an identifier. It does not tell you whether a specific flaw is being exploited in the wild, and it does not know anything about your network. CVSS is a scoring method. It takes characteristics of a vulnerability and produces a severity grade. Everything else, including how that grade fits your environment, is your job.
What a CVSS Score Actually Means (0.0 to 10.0)
A CVSS score is a number on a continuous scale from 0.0 to 10.0. Higher means more severe. The score is computed from a set of metrics that describe how the vulnerability behaves, not from a human opinion typed into a box.
The number captures intrinsic severity. It blends two ideas. The first is exploitability, meaning how hard it is for an attacker to take advantage of the flaw. The second is impact, meaning what an attacker gains if they succeed, expressed in terms of confidentiality, integrity, and availability. A vulnerability that is trivial to exploit over the network with no privileges and that fully compromises a system will score near the top. A vulnerability that requires local access, high privileges, and yields only a small information leak will score low.
Because the value is a decimal, you will see scores like 7.5 or 9.1 rather than round numbers. The decimal precision can feel scientific, but it is the direct output of the formula. The right way to read a single score is as a relative grade of how bad the flaw is in the abstract, before you consider where it lives in your estate.
Reading a CVSS Vector String
Every CVSS score travels with a vector string. The vector is the part most people skip, and it is the part that actually tells you why the score is what it is. Learning to read it turns CVSS from a mysterious number into a short, structured statement.
A vector string is a compact list of metric abbreviations and their selected values, separated by slashes. A typical version 3.1 base vector looks like this:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HEach pair is a metric and the value chosen for it. Reading the example above from left to right tells a complete story:
AV:Nmeans Attack Vector is Network, so the flaw can be reached remotely.AC:Lmeans Attack Complexity is Low, so no special conditions are required.PR:Nmeans Privileges Required is None, so the attacker needs no account.UI:Nmeans User Interaction is None, so no victim has to click anything.S:Umeans Scope is Unchanged, so the impact stays within the affected component.C:H,I:H,A:Hmean the impact on Confidentiality, Integrity, and Availability is High.
That single line describes a remote, unauthenticated, no-interaction, full-impact vulnerability. The score that comes out of it is high precisely because every input points in the dangerous direction. Once you can read a vector, you can sanity-check any score you are handed. If a finding is rated Critical but the vector shows AV:L and PR:H, you have grounds to question the urgency for your context.
Base, Temporal and Environmental Metrics
CVSS organizes its metrics into groups, and knowing the groups is what separates a surface reading from a real one.
The Base metric group describes the intrinsic qualities of the vulnerability that do not change over time or across environments. These are the metrics in the vector example above. The Base score is the one almost everyone quotes, and it is what national databases publish.
The Temporal metric group, renamed Threat in version 4.0, adjusts the base score for factors that change as the world reacts to a vulnerability. These include whether working exploit code exists and whether a fix has shipped. Temporal metrics can only lower or hold the base, never raise it, because they describe the maturity of the threat rather than new severity.
The Environmental metric group lets you re-score the vulnerability for your own deployment. You can raise or lower the weight of confidentiality, integrity, or availability based on what the affected asset does, and you can override the base exploitability metrics to match your real network. This is the group that most teams never fill in, and it is the group that makes CVSS relevant to your environment. A flaw in a system holding no sensitive data and sitting behind several controls deserves a different environmental score than the same flaw on an internet-facing crown jewel.
In practice, the score you see in a scanner or database is almost always the Base score alone. That is worth remembering every time you read one.
CVSS Severity Bands: None, Low, Medium, High, Critical
Numbers are precise but hard to act on at a glance, so FIRST defines a qualitative severity rating scale that maps score ranges to plain-language labels. This is the source of the familiar Critical, High, Medium, and Low tags you see across security tooling.
The standard bands are:
- None: 0.0
- Low: 0.1 to 3.9
- Medium: 4.0 to 6.9
- High: 7.0 to 8.9
- Critical: 9.0 to 10.0
These bands are the bridge between the math and human decision making. A team rarely says “treat anything above 7.2 as priority work.” It says “treat Highs and Criticals first.” The bands make that kind of rule possible.
Two cautions apply. First, the boundaries are firm, so a 6.9 is labeled Medium and a 7.0 is labeled High even though the underlying risk barely differs. Treat findings near a boundary with care rather than letting the label do all the thinking. Second, the labels describe severity, not priority. A Critical that cannot be reached from anywhere an attacker can stand is less urgent than a High sitting on your perimeter. The band is an input to prioritization, not the answer.
CVSS v3.1 vs v4.0: What Changed
For years, version 3.1 was the working standard and remains the version behind most published scores today. FIRST released version 4.0 to address known weaknesses, and the two will coexist in real data for a long time. You should be able to recognize both.
The headline changes in version 4.0 are worth knowing at a definitional level:
- Clearer naming. The Temporal group became the Threat group, which better reflects what it captures.
- Finer base metrics. Version 4.0 splits the old User Interaction metric into Passive and Active values, and it adds an Attack Requirements metric alongside Attack Complexity to describe conditions an attacker cannot control.
- Explicit supplemental metrics. Version 4.0 adds optional metrics such as Automatable, Recovery, and Safety that carry useful context without changing the numeric score.
- A push toward fuller scoring. Version 4.0 was designed to discourage quoting the base score alone. Its naming, including labels like CVSS-B and CVSS-BTE, signals which metric groups were actually used, so a base-only score is visibly distinct from one that includes threat and environmental input.
You can tell the versions apart from the vector itself. A version 3.1 string starts with CVSS:3.1/ and a version 4.0 string starts with CVSS:4.0/. When you compare findings across tools, check the version before assuming two scores are directly comparable, because the metrics behind them are not identical.
CVSS Is Not the Same as Risk
This is the single most important point in the entire topic, and it is the one most often missed. CVSS measures the severity of a vulnerability. It does not measure your risk.
Severity is a property of the flaw. Risk is a property of the flaw in a specific place, against a specific threat, protecting a specific asset. A CVSS base score knows nothing about whether the affected system is exposed to the internet, whether it holds regulated data, whether a compensating control blocks the attack path, or whether anyone is actually exploiting the vulnerability right now. Those factors can swing real risk dramatically while the base score stays frozen.
FIRST is explicit about this. The Base score is intended to be refined with the Environmental metrics for exactly this reason, and the standard cautions against treating a base score as a final risk verdict. Two other signals fill the gaps CVSS leaves open:
- EPSS, the Exploit Prediction Scoring System, also from FIRST, estimates the probability that a vulnerability will be exploited in the near term. A high CVSS score with a very low EPSS probability is a different situation than a high score with a high probability.
- KEV, the CISA Known Exploited Vulnerabilities catalog, lists flaws confirmed to be exploited in the wild. A vulnerability on the KEV list earns urgency that no CVSS number can express on its own.
The working takeaway is simple. Use CVSS to grade severity, then layer exposure, asset value, exploit likelihood, and known exploitation on top to reach a risk-based priority. CVSS is a strong starting input and a poor finishing answer.
How CVSS Relates to CVE and CWE
CVSS rarely appears alone. It usually sits beside two other identifiers, CVE and CWE, and people often blur the three together. They answer different questions, and keeping them straight makes any vulnerability record easier to read.
- CVE is an identifier. A CVE ID such as CVE-2024-12345 names one specific, publicly disclosed vulnerability. It is a label, not a score.
- CWE is a category. A CWE ID such as CWE-89 names a type of weakness, in that case SQL injection. Many different CVEs can share the same CWE because they are instances of the same underlying flaw class.
- CVSS is a score. It grades how severe a given vulnerability is, and it is typically attached to a CVE.
A clean way to hold the relationship is this. CWE tells you what kind of mistake it is. CVE tells you which specific instance you are looking at. CVSS tells you how bad that instance is. The three travel together on a well-formed vulnerability record, each carrying a different slice of meaning.
For the hands-on practice of reading these three identifiers together inside a vulnerability template library, including how a platform matches them to incoming findings, see our companion guide on CVSS, CWE and CVE in practice. This article stays on the CVSS definition so it does not repeat that material.
How Platforms Use CVSS in Findings
CVSS is most useful when it stops being a number in a PDF and becomes a structured field your tooling can act on. A vulnerability management platform stores CVSS as data rather than text, which lets it carry the score with every finding and reuse it for triage and reporting.
In PMAP, CVSS lives in the vulnerability template library, which is the platform-level catalog of known vulnerability classes. Each template carries a cvss_vector string and a cvss_score value, stored alongside the template’s CVE and CWE identifiers and its remediation guidance. When a finding arrives from any scanner, the platform matches it against the template library and can apply the template’s CVSS context to the finding through auto-fill. The result is that a finding does not depend on whatever a single scanner happened to report. It inherits a consistent, centrally authored severity grade.
Storing both the vector and the score matters. The score gives you the at-a-glance grade and the severity band. The vector gives an analyst the full justification, so a triage decision can be checked rather than taken on faith. Because the same templates are matched across every connected scanner, two tools that describe the same vulnerability resolve to the same CVSS context instead of disagreeing in your console. That consistency is what makes the score trustworthy enough to drive workflow. CVSS triage in context is part of the broader enrichment picture, which we cover in the pillar on vulnerability intelligence and enrichment for triage.
Common Mistakes When Interpreting CVSS
CVSS is easy to read and easy to misread. A handful of mistakes show up again and again, and avoiding them is most of what good CVSS literacy looks like.
- Treating the base score as risk. This is the central error. A base score is intrinsic severity with no knowledge of your environment. Acting on it as if it were a final risk ranking will send effort to the wrong findings.
- Ignoring the environmental metrics. The group designed to make CVSS fit your network is the one most teams skip. Skipping it throws away the part of the standard that was built for you.
- Reading the number and ignoring the vector. The vector explains the score. A high number with a benign vector for your context, such as a local-only attack vector, deserves a second look before it jumps the queue.
- Sorting a backlog by score alone. Two findings can share a 9.1 while one sits on an internet-facing asset and the other on an isolated test box. The score cannot tell them apart, so something else must.
- Mixing versions without noticing. A version 3.1 score and a version 4.0 score are not produced by identical metrics. Comparing them as if they were the same scale leads to quiet mistakes.
- Forgetting exploitation signals. CVSS does not know whether a flaw is being attacked today. Pairing it with EPSS and the KEV catalog closes that gap.
The shared theme is that CVSS is one input. Read the vector, respect the version, adjust for your environment, and combine the score with exposure and exploitation signals. Do that and CVSS becomes a sharp tool. Trust the bare number alone and it becomes a misleading one.
Frequently Asked Questions
What is a CVSS score?
A CVSS score is a number from 0.0 to 10.0 that grades the severity of a software vulnerability under the Common Vulnerability Scoring System, an open standard maintained by FIRST. The score is computed from metrics describing how exploitable the flaw is and what impact it has, and it is published with a vector string that records the exact inputs used.
What does a CVSS score of 9.8 mean?
A 9.8 falls in the Critical band, which covers 9.0 to 10.0, so it describes a vulnerability whose intrinsic severity is near the top of the scale. A score that high usually means the flaw is remotely reachable, easy to exploit, needs no privileges or user interaction, and fully compromises confidentiality, integrity, and availability. It signals high severity, but it does not by itself tell you how exposed the affected asset is in your environment.
Is a higher CVSS score always more urgent?
No. CVSS measures severity, not urgency in your context. A High on an internet-facing asset that is being actively exploited can be more urgent than a Critical sitting on an isolated internal system. Urgency comes from combining the CVSS score with exposure, asset value, and exploitation signals such as EPSS probability and the CISA KEV catalog.
What is the difference between CVSS v3.1 and v4.0?
Version 3.1 is the long-standing standard behind most published scores. Version 4.0 refines it with clearer naming, such as renaming the Temporal group to Threat, finer base metrics including an Attack Requirements metric and split User Interaction values, optional supplemental metrics, and labels like CVSS-B and CVSS-BTE that show which metric groups were used. You can tell them apart because the vector string starts with either CVSS:3.1/ or CVSS:4.0/.
Is CVSS the same as risk?
No. CVSS scores the severity of a vulnerability in the abstract. Risk depends on where the vulnerability lives, what it protects, what controls surround it, and whether it is being exploited. FIRST designed the Environmental metric group precisely so teams can adjust a base score toward real risk, and signals like EPSS and KEV supply the exploitation context CVSS leaves out.
What is a CVSS vector string?
A CVSS vector string is the compact, structured record of every metric value used to produce a score, written as abbreviations separated by slashes, such as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Reading it tells you why a score is what it is, because each pair states a single characteristic of the vulnerability such as attack vector or privileges required.
Can I change a CVSS score for my own environment?
Yes. The Environmental metric group is built for exactly that. It lets you re-weight confidentiality, integrity, and availability for the affected asset and override base exploitability metrics to match your real network. The result is an environmental score that reflects your deployment rather than the generic base score published in a database.
