CVSS Explained: How Vulnerability Scoring Actually Works

Every published vulnerability arrives with a number attached. CVE-2024-XXXX, CVSS 9.8. That number decides emergency change windows, board reporting, and whether an engineer gets paged at 2am. It is worth understanding exactly what it measures, and just as importantly, what it does not.

CVSS, the Common Vulnerability Scoring System, is an open standard maintained by FIRST. Its job is narrow and useful: take the technical characteristics of a vulnerability and turn them into a repeatable 0.0-to-10.0 severity score, so two analysts on opposite sides of the world grade the same flaw the same way. That repeatability is the whole point. Before CVSS, severity was whatever the vendor's marketing department felt like calling it.

What the score is built from

CVSS is organised into three metric groups. Only the first is mandatory, which is why it is the one you almost always see.

Base metrics describe the vulnerability itself: how it is reached and what it breaks. These are intrinsic properties that do not change over time or between organisations. The Base score is the headline number.

Temporal metrics (v3.1) or Threat metrics (v4.0) adjust for the current state of the world: does working exploit code exist yet, is there an official fix. These move as a vulnerability ages.

Environmental metrics let you re-score the flaw for your own deployment. A database bug rated Critical everywhere might be Low on a segmented, internal-only host with no sensitive data.

The Base metrics in detail

The Base group splits into exploitability (how hard is the attack) and impact (what does a successful attack cost you).

Metric	Values	What it captures
Attack Vector (AV)	Network, Adjacent, Local, Physical	How close the attacker must be
Attack Complexity (AC)	Low, High	Whether special conditions are needed
Privileges Required (PR)	None, Low, High	Access the attacker needs beforehand
User Interaction (UI)	None, Required	Whether a victim has to do something
Scope (S)	Unchanged, Changed	Can the impact cross a security boundary
Confidentiality (C)	None, Low, High	Data disclosure
Integrity (I)	None, Low, High	Data or system modification
Availability (A)	None, Low, High	Loss of access or uptime

A remotely reachable flaw that needs no privileges, no user interaction, and fully compromises confidentiality, integrity and availability is the recipe for a 9.8 or 10.0. Move any of those toward the harder or lower-impact end and the score drops.

The Scope metric is the one people miss. It asks whether exploiting the vulnerable component lets the attacker affect resources beyond it, for example escaping a sandbox or a hypervisor. A Changed scope pushes the score up sharply because the blast radius grows.

From metrics to a number

Each metric maps to a numeric constant. The exploitability metrics combine into an exploitability sub-score, the impact metrics into an impact sub-score, and a formula merges them (with a Scope adjustment) into the final 0.0-to-10.0 value. You do not need to do this arithmetic by hand. The NVD CVSS calculator shows the vector string and the resulting score as you click.

The output is both a number and a vector string, a compact record of every choice, for example CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The vector matters more than the number, because it is auditable. Anyone can read it and see why the score landed where it did.

Severity bands for v3.1:

Score	Rating
0.0	None
0.1 - 3.9	Low
4.0 - 6.9	Medium
7.0 - 8.9	High
9.0 - 10.0	Critical

What changed in CVSS v4.0

FIRST published CVSS v4.0 in 2023 to fix long-standing complaints, chiefly that v3.1 scores clustered too tightly in the 7-to-10 range and gave defenders little room to differentiate. The main changes:

• Attack Requirements (AT) is a new metric that captures conditions outside the attacker's control (race windows, specific configurations), separating them from Attack Complexity.
• User Interaction now has three levels: None, Passive, and Active, so "the victim merely has to view a page" is scored differently from "the victim must complete a multi-step action".
• Scope is gone. In its place, impact is scored twice: on the Vulnerable System and on the Subsequent System. This is a cleaner way to express blast radius.
• Supplemental metrics were added, including Safety, Automatable, Recovery, and Value Density. These do not change the number; they carry context a defender can act on.
• Nomenclature makes the scope of a score explicit: CVSS-B (Base only), CVSS-BT (Base + Threat), CVSS-BTE (Base + Threat + Environmental).

The Temporal and Threat metrics

The second metric group is the one most people never see, because public scores rarely include it. In v3.1 it is called Temporal, and in v4.0 it is folded into the Threat metric group. Its job is to adjust the Base severity for the current state of the world around a flaw, which changes as the flaw ages.

In v3.1 the Temporal group has three metrics. Exploit Code Maturity captures whether working exploit code exists and how reliable it is, ranging from unproven through proof-of-concept to functional and high. Remediation Level records whether a fix is available, from an official patch through a temporary workaround down to unavailable. Report Confidence reflects how sure the world is that the flaw is real and well understood. Each of these can only lower or leave unchanged the Base score, never raise it above the Base ceiling, so the Temporal score sits at or below the Base number.

v4.0 simplifies this considerably. It replaces the three Temporal metrics with a single Threat metric focused on exploit maturity, on the reasoning that the presence and maturity of exploitation is the piece of time-varying information defenders most need. The effect is the same in spirit: take the intrinsic Base severity and temper it with what is currently known about real-world exploitation and available fixes.

The Environmental metrics

The third group lets you re-score a flaw for your own deployment, and it is where CVSS becomes genuinely useful for prioritisation rather than a generic label. The Environmental metrics come in two parts.

First, you can override any Base metric to reflect your situation. If a flaw requires network access in general but the affected service is only reachable from an isolated internal segment in your environment, you can set Attack Vector accordingly and the score drops. Second, you can weight the impact metrics by how much confidentiality, integrity, and availability matter for the specific asset, using Security Requirements. A confidentiality-shattering flaw on a system that holds nothing sensitive scores lower once you tell the model that confidentiality is a low requirement there; the same flaw on a system full of regulated data scores higher.

The Environmental group is why the same CVE can be Critical for one organisation and Medium for another. The Base score is a starting point that assumes a generic, worst-reasonable deployment. Applying the Environmental metrics turns that generic figure into one that reflects where the flaw actually lives in your estate, which is the version of the score worth acting on.

Why the score alone will mislead you

Here is the trap. The score you see on a CVE page is almost always Base-only, because the person publishing it does not know your environment and often does not yet know whether an exploit exists. Base-only scoring answers one question well: how bad is this if someone uses it. It says nothing about whether anyone will.

The result is a patch queue full of 9.8s, most of which will never be exploited, sitting next to a "medium" 6.5 that is being weaponised in the wild right now. Sort purely by CVSS and you will spend your week on the wrong flaws.

Two freely available signals fix this:

• EPSS estimates the probability a vulnerability will be exploited in the next 30 days. It is the missing likelihood axis. See EPSS Explained.
• CISA KEV is a catalog of vulnerabilities known to be exploited right now. If a CVE is on it, urgency is no longer a guess. See The KEV Catalog Explained.

The practical rule: CVSS for severity, EPSS for likelihood, KEV for confirmation. A flaw that is high on all three is a genuine emergency. A 9.8 with a near-zero EPSS and no KEV listing can usually wait for the normal patch cycle.

How to actually use CVSS

1. Treat the public Base score as a filter, not a verdict. It narrows the field; it does not rank it.
2. Re-score with Environmental metrics for anything that matters. A Critical flaw on an isolated test box is not a Critical problem.
3. Join it to EPSS and KEV before you set the patch order. Severity times likelihood beats severity alone every time.
4. Keep the vector string, not just the number. When someone challenges a rating six months later, the vector is your evidence.

CVSS is a good answer to a specific question. Ask it the right question, pair it with the signals it was never designed to provide, and it becomes the backbone of a defensible vulnerability programme. Use the number on its own and it becomes a very precise way to prioritise badly.

Reading a vector string, field by field

The number is a summary; the vector string is the evidence. Learning to read it turns CVSS from a black box into something you can audit. Take the example CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and walk it left to right.

The prefix CVSS:3.1 states the version, which matters because the same metrics can mean subtly different things across versions. AV:N is Attack Vector Network, meaning the flaw is reachable over a network rather than requiring local or physical access, the broadest and most dangerous reach. AC:L is Attack Complexity Low, meaning no special conditions outside the attacker's control are needed. PR:N is Privileges Required None, so the attacker needs no prior access. UI:N is User Interaction None, so no victim has to click or open anything.

Those four exploitability metrics together describe a flaw anyone can reach and trigger at will. The next field, S:U, is Scope Unchanged, meaning the impact stays within the vulnerable component and does not cross into other security authorities. Then come the three impact metrics: C:H, I:H, and A:H, High confidentiality, integrity, and availability impact, meaning a successful attack fully compromises the data and the system's operation.

Read as a sentence, the vector says: reachable over the network, easy, no privileges, no user interaction, contained scope, total impact on all three of confidentiality, integrity, and availability. That combination is what produces a score in the 9-plus range. Change AV:N to AV:L and the reach narrows to local access, dropping the score. Change UI:N to UI:R and the attack now needs a victim to act, dropping it further. The value of the string is that anyone can perform this reading and see why the number landed where it did, which is what makes a score defensible six months later.

A worked scoring example

Consider a flaw described in plain terms: an unauthenticated attacker who can send a crafted request to a service over the network can read arbitrary files from the server, but cannot modify anything or take the service down. Score it metric by metric.

Attack Vector is Network, because the request travels over the network. Attack Complexity is Low, assuming no unusual preconditions. Privileges Required is None, because the attacker needs no account. User Interaction is None, because no victim participates. Scope is Unchanged, because reading files affects the vulnerable component's own authority. For impact, Confidentiality is High, since arbitrary file read is a serious disclosure. Integrity is None, because nothing can be modified. Availability is None, because the service keeps running.

That yields a vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. The impact is real but one-dimensional, confidentiality only, so the score lands in the High band rather than Critical. Change the flaw so the attacker can also modify files, raising Integrity to High, and the score climbs because two impact dimensions are now maxed. This is the useful discipline CVSS enforces: it forces you to separate how reachable a flaw is from how much damage it does, and to be explicit about each.

How CVSS relates to EPSS and KEV

CVSS is one of three widely used signals, and confusing their purposes is the most common mistake in vulnerability prioritisation. Each answers a different question, and they are complementary rather than competing.

Signal	Question it answers	What it is based on	What it does not tell you
CVSS	How bad is this if exploited	Intrinsic technical properties	Whether it will be exploited
EPSS	How likely is exploitation soon	Statistical model of observed activity	How much damage it would do
CISA KEV	Is it being exploited now	Confirmed real-world exploitation	Future likelihood or severity

CVSS gives severity, the ceiling on how much harm a flaw could do. EPSS gives likelihood, a probability that exploitation will occur in the near term. KEV gives confirmation, a binary statement that exploitation is already happening. A flaw that scores high on all three is a genuine emergency. A CVSS 9.8 with a near-zero EPSS and no KEV listing is a theoretical ceiling with little pressure behind it, and can usually wait for the normal patch cycle. Sorting a patch queue by CVSS alone puts the theoretical ceiling above the flaw that is actively under attack, which is exactly backwards.

Common mistakes and misconceptions

"The CVSS score tells me how urgent this is." It tells you how severe the flaw could be, which is only part of urgency. Urgency also depends on likelihood and confirmation of exploitation, which CVSS does not measure. A severe flaw nobody is exploiting is less urgent than a moderate flaw under active attack.

"A higher number always means patch it first." Base scores cluster in the high range, so a queue full of 9.8s gives little to differentiate. Re-scoring with environmental context and joining to EPSS and KEV separates the genuinely pressing from the merely severe far better than the raw number.

"The score accounts for my environment." The public score almost never does. It is Base-only, computed without knowledge of your deployment. A flaw that is Critical in general can be low-impact on an isolated internal host with no sensitive data, which only the Environmental metrics, applied by you, can express.

"CVSS measures risk." Risk combines the likelihood of an event with its impact. CVSS measures a form of impact severity, not likelihood, so it is one input to risk rather than a risk score itself. Treating it as risk overweights severe flaws that will never be exploited.

"v4.0 makes older scores meaningless." v3.1 scores remain valid and widely used, and the two versions coexist. v4.0 improves differentiation and adds context, but a v3.1 vector is still a legitimate, auditable record. What matters is knowing which version and which metric groups a given score reflects, which the version prefix and nomenclature make explicit.

Frequently asked questions

What does the CVSS number actually represent? It represents the severity of a vulnerability, a 0.0 to 10.0 measure of how it is exploited and how much damage a successful attack causes, derived from a fixed formula over a set of metrics. It is a repeatable severity rating, so different analysts grade the same flaw the same way. It deliberately says nothing about how likely the flaw is to be exploited in practice.

Why is my CVE showing only a Base score? Because the person publishing it usually cannot know your environment and often does not yet know whether working exploit code exists. Base metrics are the intrinsic, unchanging properties of the flaw, so they are what can be published for everyone. The Temporal or Threat and Environmental metrics require information specific to a point in time or a deployment, which you supply yourself.

Should I use CVSS v3.1 or v4.0? Use whichever the source provides, and understand its metrics. v4.0 offers finer differentiation and better context through Attack Requirements, a three-level User Interaction, dual system impact in place of Scope, and supplemental metrics. Many sources still publish v3.1, and both remain valid. Consistency and knowing which version you are reading matter more than always choosing one.

Is a 10.0 the worst possible vulnerability? It is the maximum severity the formula expresses: network-reachable, no privileges, no user interaction, and full impact, often with a scope change. It is not a statement that the flaw will be exploited or that it matters in your environment. A 10.0 that is not reachable in your deployment or that nobody is exploiting can be less pressing than a lower-scored flaw under active attack.

How does the Scope metric change the score? In v3.1, Scope captures whether exploiting the vulnerable component lets the attacker affect resources beyond it, such as escaping a sandbox. A Changed scope raises the score sharply because the blast radius grows past the original component. v4.0 replaces this single flag with separate impact scoring for the vulnerable system and any subsequent system, a cleaner way to express the same idea of impact crossing a boundary.

Can I rely on CVSS alone to run a patch programme? Not effectively. On its own it produces a queue dominated by severe flaws regardless of whether they are exploited, so you spend effort on the wrong ones. Combine it with EPSS for likelihood and CISA KEV for confirmation, and re-score important assets with Environmental metrics. Used that way, CVSS is a strong backbone; used alone, it is a precise way to prioritise badly.

Why do two sources sometimes give different CVSS scores for the same flaw? Because scoring involves judgment about each metric, and reasonable analysts can differ on values like Attack Complexity or the exact impact. Different sources may also score different configurations of the same flaw. This is why the vector string matters: it exposes the specific choices behind a score, so you can see where two sources diverged and decide which reading fits your situation.

Related guides

• EPSS Explained
• The KEV Catalog Explained
• The CVE System Explained
• Vulnerability Management Lifecycle
• Zero-Day Vulnerabilities