A CVSS v3.1 score is a number from 0.0 to 10.0 that describes how severe a vulnerability is, based on how it can be exploited and what an attacker gains. To read one properly, look past the number to the vector string that comes with it, such as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Each pair in that string is a metric and its value, and together they explain the score. What the score won't tell you is whether anyone is exploiting the flaw, how exposed your system is, or how much that system matters to your business.
This post walks through a vector string metric by metric, explains the three metric groups, covers what changed in version 3.1, and sets out the gaps you have to fill yourself.
What is CVSS v3.1?
The Common Vulnerability Scoring System is an open standard maintained by FIRST, the Forum of Incident Response and Security Teams. It gives vendors, researchers and vulnerability databases a shared way to describe a vulnerability's characteristics and turn them into a score.
Version 3.1 is the current release. FIRST published it in mid-2019, with the formal announcement in July, and it replaces version 3.0 from 2015. The National Vulnerability Database (NVD), run by NIST, began using v3.1 for new and re-analyzed CVEs on September 10, 2019.
What changed from CVSS v3.0 to v3.1?
Version 3.1 is a refinement, not a redesign. The CVSS v3.1 User Guide says the changes clarify and improve the existing standard "without introducing new metrics or metric values." The main differences:
- Clearer definitions. The explanation of Scope was rewritten to be clearer, along with the concepts of the vulnerable component and the impacted component. Attack Vector, Privileges Required and the Security Requirements metrics also got clearer wording.
- A formally defined Roundup function. Rounding in 3.0 was less precisely specified, so two calculators could produce different scores because of tiny floating-point errors. Version 3.1 defines Roundup precisely.
- Environmental formula changes. The Modified Impact sub-formula used when Modified Scope is Changed was adjusted. In 3.0, some combinations produced a lower score when you raised a metric, which made no sense.
- An extensions framework. Industry sectors such as healthcare or automotive can now add their own metrics in a standard way while keeping the official Base, Temporal and Environmental metrics intact.
- Better scoring guidance. The User Guide now states plainly that CVSS measures severity, not risk, and adds guidance on scoring vulnerabilities in software libraries.
The vector string also changed. It now begins CVSS:3.1 rather than CVSS:3.0, so the prefix tells you which rules the scorer followed. The Base formula itself is unchanged apart from the more precise rounding, so the formula changes mainly affect Environmental scores.
How do you read a CVSS vector string?
Take this example, which scores 9.8 (Critical):
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
After the version prefix come the eight Base metrics. Here is what each value in the example means:
| Metric | Value | What it means here |
|---|---|---|
| Attack Vector (AV) | N (Network) | Exploitable remotely across a network |
| Attack Complexity (AC) | L (Low) | No special conditions the attacker can't control |
| Privileges Required (PR) | N (None) | No account or prior access needed |
| User Interaction (UI) | N (None) | No user has to do anything |
| Scope (S) | U (Unchanged) | Impact stays within the vulnerable component |
| Confidentiality (C) | H (High) | Total loss of confidentiality |
| Integrity (I) | H (High) | Total loss of integrity |
| Availability (A) | H (High) | Total loss of availability |
In plain English: an unauthenticated attacker can exploit this over the network, reliably, without anyone's help, and take full control of the affected component's data and availability. That is about as bad as a single vulnerability gets.
Exploitability metrics: AV, AC, PR and UI
These four describe how hard the vulnerability is to exploit. Attack Vector runs from Network through Adjacent (same local segment or a limited-access network) and Local (the attacker needs local access or a user to open something) to Physical. Attack Complexity is High when success depends on conditions outside the attacker's control, such as winning a race condition or gathering target-specific information first.
Privileges Required is None, Low or High, depending on what level of access the attacker needs before exploiting the flaw. User Interaction is either None or Required. If the attack only succeeds when a user takes some action, such as opening a crafted file, the value is Required and the score drops.
Change just two of these and the picture shifts. CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, a typical local privilege escalation, scores 7.8 (High). The impact is identical, but the attacker already needs a foothold on the machine.
Scope: S
Scope asks whether exploiting the vulnerable component can affect resources beyond its security authority. If a flaw in a guest virtual machine lets an attacker affect the host, or a flaw in a web application lets an attacker run script in a visitor's browser, the scope is Changed. A Changed scope raises the score, because the damage reaches past the component that has the bug.
Most vulnerabilities are Scope Unchanged. When you see S:C, read the impact metrics as describing the component that ends up affected, which may not be the one you're patching.
Impact metrics: C, I and A
Confidentiality, Integrity and Availability are each rated None, Low or High. High means total loss, or a serious consequence even if the loss is partial. Low means limited impact: some data exposed, some data modifiable, or reduced performance. These describe the worst reasonable outcome for the affected component, not for your organization as a whole.
What are the Base, Temporal and Environmental metric groups?
CVSS v3.1 has three metric groups, and each answers a different question.
| Group | Question it answers | Who usually sets it | Changes over time? |
|---|---|---|---|
| Base | How severe is this vulnerability in itself? | Vendor, researcher or NVD | No |
| Temporal | How does the current state of exploits and fixes affect severity? | Vendor or you | Yes |
| Environmental | How severe is it in your environment? | You | Per organization |
Temporal metrics include Exploit Code Maturity (Unproven, Proof-of-Concept, Functional, High), Remediation Level (Official Fix, Temporary Fix, Workaround, Unavailable) and Report Confidence (Unknown, Reasonable, Confirmed). Each also has a Not Defined value. Temporal metrics can only keep the score the same or lower it.
Environmental metrics let you tailor the score. The Security Requirements metrics (Confidentiality, Integrity and Availability Requirement, each Low, Medium or High) weight the impact by how much each property matters for the asset. The Modified Base metrics let you override Base values where your setup differs. If a component sits on a network segment that only administrators can reach, for example, you can adjust the Modified Attack Vector. Environmental scoring can raise or lower the score.
In practice, the number you see in most advisories and tools is the Base score alone.
What do the CVSS severity ratings mean?
The CVSS v3.1 Specification maps scores to qualitative ratings:
| Rating | Score range |
|---|---|
| None | 0.0 |
| Low | 0.1–3.9 |
| Medium | 4.0–6.9 |
| High | 7.0–8.9 |
| Critical | 9.0–10.0 |
These bands are convenient for policy, such as "fix Critical within X days." Remember that the boundaries are arbitrary. A 6.9 and a 7.0 are practically the same severity, even though they may land in different remediation queues.
Why does the same vulnerability show different scores?
The NVD currently publishes both CVSS v2 and v3.x Base scores for many CVEs, and older CVEs often have only a v2 score. The two versions use different formulas and different bands. CVSS v2 has no Critical rating (High covers 7.0–10.0), so a v2 score of 7.5 and a v3.1 score of 9.8 for the same CVE don't contradict each other.
Scores can also differ by source. A software vendor may score its own vulnerability differently from the NVD, because it knows more about default configurations or has different information about impact. Your scanner might display either one. Before you argue about a number, check which version it is and who calculated it.
What doesn't a CVSS score tell you?
FIRST is explicit here: the Base score reflects the intrinsic characteristics of a vulnerability, and it is not a measure of risk. Three gaps matter most.
Whether the flaw is being exploited
A Base score doesn't change when attackers start using a vulnerability. A 9.8 that nobody has written working exploit code for may be less urgent this week than a 7.5 that is under active attack. The Temporal Exploit Code Maturity metric gets closer to this, but public Base scores leave it out. You need other inputs, such as vendor advisories, national CERT alerts and threat intelligence.
How exposed your asset is
AV:N means the vulnerability can be exploited over a network. It doesn't mean your instance is reachable from the internet. The same vulnerable service on an internet-facing server and on an isolated internal segment carries the same Base score, but very different real-world exposure.
How important the asset is
A 9.8 on a test virtual machine and a 9.8 on your finance database look identical in a report. The Environmental Security Requirements metrics are built for this, but few organizations apply them at scale. Most track asset criticality separately.
A few smaller gaps are worth knowing too. Base scores rate each vulnerability on its own, so they don't capture how two moderate flaws might chain together. They also ignore compensating controls you already have, such as segmentation or restrictive firewall rules.
How should you use CVSS in prioritization?
Treat CVSS as one input to a decision, not the decision. A practical approach:
- Read the vector, not just the number.
AV:N/PR:N/UI:Ntells you far more about urgency than "9.8" does. - Check the version and source. Know whether you're looking at v2 or v3.x, and whether the vendor or NVD scored it.
- Add exploitation evidence. Flag vulnerabilities with public exploit code or reports of active attacks.
- Add exposure and criticality. Tag assets by internet exposure and business importance in your inventory, then combine those tags with severity.
- Use Environmental scoring selectively. You don't need it everywhere. Applying it to your most critical systems can sharpen priorities where it counts.
Frequently asked questions
Is a CVSS 3.1 score comparable to a CVSS 3.0 score?
Mostly, yes. Version 3.1 added no new metrics or metric values, and the Base formula is unchanged apart from more precise rounding. Differences tend to come from Environmental scores and from analysts applying the clarified definitions, especially Scope, differently.
Does a low CVSS score mean I can ignore a vulnerability?
No. A Low or Medium vulnerability on an exposed, business-critical system, especially one with public exploit code, may deserve faster action than a Critical on an isolated test box. It can also be one link in a chain of flaws.
Who is supposed to calculate the Environmental score?
You are. Only you know your assets, your network layout and how much confidentiality, integrity and availability matter for each system. Vendors and the NVD can't do this for you.
Key takeaways
- A CVSS v3.1 score measures the severity of a vulnerability on a 0.0–10.0 scale. It doesn't measure your risk.
- The vector string explains the score. Learn to read AV, AC, PR, UI, S and C/I/A at a glance.
- Version 3.1 clarified definitions (especially Scope), formally defined Roundup, fixed the Environmental formulas and added an extensions framework, without adding new metrics.
- Most published scores are Base scores. Temporal and Environmental adjustments are largely up to you.
- Fill the gaps with evidence of exploitation, the asset's exposure and its business importance before deciding what to fix first.