How CVSS Scoring Works

Every CVE entry on NVD carries a number between 0.0 and 10.0. Security teams treat it as a priority signal. Executives treat it as a risk indicator. And a surprising number of people in both groups aren’t entirely sure what goes into it. The Common Vulnerability Scoring System — CVSS — has been the de facto standard for vulnerability severity since version 1.0 in 2004 and is now on version 3.1, with version 4.0 published in 2023 and slowly gaining adoption. The full specification lives at FIRST.org, maintained by the Forum of Incident Response and Security Teams, and it is longer than most people expect.

What follows is a practical read of how CVSS 3.1 works, where it falls short, and what else you should be looking at alongside it.

The Base Score

The CVSS base score is calculated from eight metrics grouped into two categories: exploitability and impact.

Exploitability metrics describe how an attacker reaches the vulnerability:

• Attack Vector (AV): How remote can an attacker be? Network (N) is fully remote — attackable over the internet. Adjacent (A) requires the attacker to be on the same local network. Local (L) requires local access. Physical (P) requires physical access to the device.
• Attack Complexity (AC): Does the attack require specific conditions to succeed beyond attacker control? Low (L) means the attack is reproducible without special conditions. High (H) means it requires something the attacker doesn’t fully control — a timing window, a specific configuration, a race condition.
• Privileges Required (PR): Does the attacker need existing privileges on the target system? None (N), Low (L — a standard user account), or High (H — administrative or root access).
• User Interaction (UI): Does a legitimate user need to take an action for the attack to succeed? None (N) or Required (R — e.g., a user must click a link or open a file).

Impact metrics describe what an attacker can do after exploiting the vulnerability:

• Scope (S): Can the attack affect components beyond the vulnerable component? Unchanged (U) means the impact stays within the same security scope. Changed (C) means the attacker can affect other components — for example, escaping a container to affect the host.
• Confidentiality (C), Integrity (I), Availability (A): Each rated None (N), Low (L), or High (H) — measuring the degree of access to data, ability to modify data, and ability to disrupt service, respectively.

These eight metrics feed into a formula that produces the base score. The exact formula is published in the CVSS 3.1 specification; most practitioners don’t need to calculate it by hand, but understanding the inputs explains why seemingly similar vulnerabilities score differently. An unauthenticated, network-accessible remote code execution vulnerability with no user interaction and full confidentiality, integrity, and availability impact will score a 9.8 or 10.0. A locally exploitable information disclosure affecting only low-privilege accounts might score a 3.x.

Severity bands defined by NVD and FIRST:

Score Range	Severity
0.0	None
0.1 – 3.9	Low
4.0 – 6.9	Medium
7.0 – 8.9	High
9.0 – 10.0	Critical

Temporal and Environmental Metrics

The base score assumes worst-case conditions: no patches exist, no compensating controls are deployed, and the vulnerability is fully understood by attackers. Two optional modifier layers can adjust this:

Temporal metrics account for exploitation dynamics at a point in time. If a patch has shipped, that brings the score down relative to the “unpatched” base. If a proof-of-concept is publicly available, exploitation is now easier than the base score assumed — which can push effective risk up. Temporal scores are time-sensitive by design; NVD doesn’t always publish them, but security vendors and threat intelligence platforms sometimes do.

Environmental metrics let an organization adjust the score for their specific context. If your deployment doesn’t expose the affected component to the network at all, the attack vector changes. If you have compensating controls that raise the effective attack complexity, that factors in. Environmental scoring is the most useful modifier for actual patching decisions, and the least commonly used, because it requires organizations to know their asset context in detail — which is harder than it sounds.

Reading a CVE’s NVD Page

When you pull up a CVE on the NVD, you’ll see the CVSS vector string alongside the score. A vector string looks like this:

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

This decodes to: Attack Vector Network, Attack Complexity Low, Privileges Required None, User Interaction None, Scope Unchanged, Confidentiality High, Integrity High, Availability High. That particular combination scores a 9.8 — critical. Reading the vector string directly tells you more than the number alone, because it tells you why the score is what it is and whether that scenario matches your environment.

NVD also publishes CVSS scores from the CVE Numbering Authority (CNA) — the vendor or organization that assigned the CVE — which sometimes differs from NVD’s own analysis. If you see two CVSS scores on a CVE page, note the source. Vendor-supplied scores occasionally favor lower severity.

Why CVSS Base Score Isn’t Risk

This is where most of the confusion lives.

CVSS base score measures theoretical severity in a reference scenario. It doesn’t measure:

• Whether the vulnerability is actually being exploited
• Whether your organization is running the affected software
• Whether compensating controls reduce your actual exposure
• Whether an exploit exists and is usable

A CVE with a 9.8 base score that affects software you don’t run is not a risk to you. A CVE with a 5.x score that affects a component exposed to the internet with no compensating controls and an active PoC circulating might be your most urgent issue right now.

Two supplementary signals help close the gap:

EPSS (Exploit Prediction Scoring System) from FIRST.org produces a daily probability estimate — between 0 and 1 — of a given CVE being exploited in the next 30 days. A CVE with a CVSS 7.x score and an EPSS above 0.5 is likely more urgent than a CVSS 9.8 with an EPSS of 0.01. EPSS is based on observed internet data from honeypots, threat feeds, and exploitation telemetry; it’s not infallible, but it’s a materially better predictor of near-term exploitation than CVSS alone.

KEV status — CISA’s Known Exploited Vulnerabilities catalog — is the definitive signal that exploitation has already been confirmed. A KEV entry supersedes any CVSS-based prioritization argument: the vulnerability is being used against real targets right now. The KEV Tracker on this site maintains a current, filterable view of the catalog alongside EPSS and severity data. There’s also a longer explainer on what the KEV catalog is and how it works.

Practical Takeaway

CVSS is a useful first filter. It standardizes severity language across thousands of CVEs from hundreds of vendors and gives vulnerability management tools a common denominator for triage. But using it as the only filter produces a queue that doesn’t reflect actual risk — a queue full of high-CVSS CVEs in software you don’t run, while actively-exploited medium-severity issues go unpatched because the number was less alarming.

Effective patch prioritization combines CVSS base score with EPSS probability, KEV status, and asset context. CVSS tells you what would happen in a worst-case scenario. The other signals tell you how likely that scenario actually is — and whether it’s already playing out.

The number is a starting point.