CVSS turns a vulnerability into a number between 0.0 and 10.0, and that number ends up driving remediation deadlines, contract obligations and audit findings. Which makes it worth understanding what the score is actually measuring — and, just as importantly, what it deliberately ignores.

Score one with the CVSS v3.1 Calculator, which shows the vector and explains each metric as you set it.

The eight base metrics

A base score comes from eight values. They fall into two groups: how hard the attack is, and how bad the outcome is.

Exploitability

Attack Vector (AV) — Network, Adjacent, Local or Physical. Network is the most severe: reachable from anywhere. This single metric moves the score more than any other.

Attack Complexity (AC) — Low or High. High means conditions exist outside the attacker's control, such as winning a race condition. If an attacker can simply retry until it works, that is Low.

Privileges Required (PR) — None, Low or High. None means no account at all.

User Interaction (UI) — None or Required. Does a victim have to click something?

Impact

Scope (S) — Unchanged or Changed. The metric people get wrong most often. Changed means the vulnerability lets an attacker affect resources beyond the security authority of the vulnerable component — a container escape, a browser sandbox break, a hypervisor breakout. It raises the score sharply, so it deserves care rather than optimism.

Confidentiality, Integrity, Availability (C/I/A) — None, Low or High, each. What an attacker can read, change and disrupt.

Reading a vector string

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

That is 9.8, Critical. In words: reachable over the network, no special conditions, no privileges, no user interaction, and total loss of confidentiality, integrity and availability. Unauthenticated remote code execution.

Compare:

CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N

That is 1.6, Low. Local access, difficult conditions, admin privileges already required, a user must act, and it leaks a little information. Real, but not urgent.

Always publish the vector alongside the number. The score alone is unarguable; the vector shows your reasoning and lets someone disagree with a specific metric rather than the conclusion.

The severity bands

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

Boundaries matter more than they should, because policies are written against them. A 6.9 and a 7.0 are practically identical and land in different SLA buckets. If a score sits on a boundary, the honest move is to note that in the report rather than nudge a metric to land where you would prefer.

What CVSS deliberately ignores

This is the part that causes arguments, and it is by design.

Base score assumes reasonable worst case. It does not know whether the affected system is your payment platform or a decommissioned test box nobody can reach.

It does not know about your compensating controls. A network-facing vulnerability on a host behind a firewall that permits three internal addresses is much less exposed than the base score implies.

It does not measure exploitation in the wild. A 9.8 with no public exploit and a 7.5 being actively exploited in ransomware campaigns are not equally urgent — and the 7.5 is the one to fix first.

It says nothing about business impact. A Medium in a system holding regulated data can matter more than a High in a marketing microsite.

CVSS provides Temporal and Environmental metric groups to account for some of this, and almost nobody uses them. The practical answer is to publish the base score, then add a short paragraph of context explaining why you are treating it as more or less urgent than the number suggests.

Common scoring mistakes

Inflating Scope. Scope changes only when the attacker crosses a security authority boundary. Reading files as the web server user is not a scope change; escaping the container is.

Confusing AC with effort. Attack Complexity is about conditions beyond the attacker's control, not about how much work it takes. A tedious but reliable attack is Low.

Scoring PR from the victim's perspective. Privileges Required means what the attacker needs before starting, not what the vulnerable function normally requires.

Marking impact High reflexively. High means total loss. Partial disclosure of limited data is Low. Consistency matters more than severity here — a report where everything is Critical stops being useful.

Using it well in a report

  1. Score the vulnerability as it exists, not as you fear it might.
  2. Include the full vector string, always.
  3. Add one sentence justifying any metric a reader might dispute — especially Scope.
  4. Follow with context: what this system holds, what controls sit around it, whether exploitation is known.
  5. Let the client set priority. Your job is an accurate score and honest context, not the remediation deadline.

Common questions

What counts as Critical?
9.0 to 10.0. Typically unauthenticated remote attacks with full impact.

When does Scope change?
Only when the attacker affects resources beyond the vulnerable component's security authority — sandbox escapes, container breakouts, hypervisor issues.

Is a 9.8 always more urgent than a 7.5?
No. A 7.5 under active exploitation outranks a 9.8 with no known exploit. Base score does not measure real-world exploitation.

Should I use Temporal and Environmental metrics?
They are useful and rarely used. A paragraph of written context usually communicates the same thing more clearly.

Where to go next