How the score is built: two sub-scores, one number
A CVSS v3.1 Base score is not one calculation — it is two sub-scores combined. Exploitability captures how easy the vulnerability is to reach and trigger. Impact captures how much damage a successful exploit does. The Scope metric decides how those two are weighted together. Understanding this split is what separates people who read CVSS scores from people who can predict them.
CVSS was first developed under the U.S. National Infrastructure Advisory Council (NIAC) and released in 2005. Ownership and maintenance passed to FIRST.org (the Forum of Incident Response and Security Teams), which publishes the specification and the official calculator. A common misconception is that NIST created CVSS — it did not. NIST runs the National Vulnerability Database (NVD), which applies CVSS scores to published CVEs, but the standard itself belongs to FIRST. CVSS v3.1 was released in June 2019 and remains the most widely used version for CVE scoring; CVSS v4.0 arrived in November 2023 and adoption is ongoing.
The CVSS severity scale — and what each band should mean for your team
The number only becomes useful when it maps to an action. The bands below are the CVSS v3.x qualitative ratings, paired with the response expectations most vulnerability-management programs codify into SLAs.
| Score | Severity | What it signals | Typical remediation SLA |
|---|---|---|---|
| 0.0 | None | No exploitable impact | No action required |
| 0.1 – 3.9 | Low | Narrow conditions, limited blast radius | 1–6 months / next maintenance window |
| 4.0 – 6.9 | Medium | Meaningful impact under specific conditions | 1–3 months |
| 7.0 – 8.9 | High | Likely to cause real damage if exploited | 1–4 weeks |
| 9.0 – 10.0 | Critical | Urgent; often remote and unauthenticated | 1–7 days (hours if actively exploited) |
The SLA column is convention, not part of the CVSS spec — but tying each band to a deadline is exactly what turns a score into a program. Which number matters most to you? For most teams the Critical and High rows drive nearly all emergency patching, while Medium and Low get batched into regular cycles.
The eight Base metrics (CVSS v3.1) explained
CVSS v3.1 calculates the Base score from eight metrics that describe the intrinsic characteristics of a vulnerability — independent of your environment or any active threat.
Attack Vector (AV) — how the vulnerability is reached.
- Network (N): exploitable remotely across the internet. Highest weight.
- Adjacent (A): requires access to the same physical or logical network (e.g., same LAN, Bluetooth range).
- Local (L): requires local access — a shell, a session, or the ability to run code on the host.
- Physical (P): requires physically touching the device. Lowest weight.
Attack Complexity (AC) — conditions outside the attacker's control.
- Low (L): repeatable exploitation with no special conditions.
- High (H): requires specific configuration, timing, or a race the attacker must win.
Privileges Required (PR) — what access the attacker needs first.
- None (N): unauthenticated.
- Low (L): a normal user account.
- High (H): administrative or root-level access.
User Interaction (UI) — whether a victim must act.
- None (N): fully self-contained.
- Required (R): someone must click, open, or run something.
Scope (S) — whether the impact stays contained.
- Unchanged (U): impact is limited to the vulnerable component's own security authority.
- Changed (C): the exploit breaks out — for example, a sandbox or container escape that affects the host. Scope Changed raises the ceiling of the score.
Confidentiality (C), Integrity (I), and Availability (A) each take None (N), Low (L), or High (H), measuring how much data disclosure, data tampering, or downtime a successful exploit causes.
Worked examples with their vector strings
Numbers stick better when you can see the exact inputs. Both of these are reproducible — paste the vector string into the calculator above and you'll get the same score.
Example 1 — Unauthenticated remote code execution in a web app
- Attack Vector: Network · Attack Complexity: Low · Privileges Required: None · User Interaction: None
- Scope: Unchanged (code runs within the app's own security context)
- Confidentiality: High · Integrity: High · Availability: High
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 (Critical)
This is the classic 9.8 — the profile of a wormable, internet-reachable bug. Now change one dial: if that same RCE escapes its component and compromises the host (Scope: Changed), the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H scores 10.0. That single Scope flip is why some Criticals are "9.8" and others are the maximum.
Example 2 — Local privilege escalation
- Attack Vector: Local · Attack Complexity: Low · Privileges Required: Low · User Interaction: None
- Scope: Changed · Confidentiality: High · Integrity: High · Availability: High
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H → 8.8 (High)
Same devastating impact, but because the attacker must already have a foothold (Local vector, a user account), the exploitability sub-score drops and the total falls into High rather than Critical.
Temporal (Threat) and Environmental metrics
The Base score is deliberately static. Two optional metric groups adjust it for reality — and most teams ignore them, which is a mistake.
Temporal metrics (renamed Threat metrics in v4.0) reflect the current state of the threat:
- Exploit Code Maturity / Exploit Maturity: is there a working, weaponized exploit in the wild?
- Remediation Level: is there an official fix, a workaround, or nothing yet?
- Report Confidence: how well-confirmed is the vulnerability?
Environmental metrics re-weight the score for your environment:
- Security Requirements (CR / IR / AR): how much do you value confidentiality, integrity, and availability on the affected asset?
- Modified Base metrics: override any Base metric to reflect your specific deployment (e.g., a network-exploitable bug that your firewall makes unreachable).
A Base 7.5 on a hardened, internet-isolated system with no known exploit is a very different priority than the same 7.5 on a public server with a Metasploit module. The Environmental group is where CVSS finally accounts for context — but only if you use it.
CVSS v3.1 vs v4.0: what actually changed
CVSS v4.0 is not a tweak — it restructures how impact is measured and how scores are named. The table below covers the differences that change day-to-day interpretation.
| Aspect | CVSS v3.1 | CVSS v4.0 |
|---|---|---|
| Impact modeling | Single Scope metric (Unchanged/Changed) | Explicit Vulnerable System (VC/VI/VA) and Subsequent System (SC/SI/SA) impact — Scope is retired |
| Exploitability inputs | AV, AC, PR, UI | Adds Attack Requirements (AT) alongside the four v3.1 metrics |
| Time-sensitive group | "Temporal" (3 metrics) | Renamed Threat; simplified to Exploit Maturity |
| Supplemental context | None | New Supplemental metrics: Safety, Automatable, Recovery, Value Density, Response Effort, Provider Urgency |
| Score naming | Base / Temporal / Environmental | Named types: CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE to discourage quoting Base alone |
| Design intent | Broad severity signal | Better fidelity for OT/ICS, safety, and real exploitability |
Which should you use? For scoring new CVEs and any greenfield program, prefer v4.0 — it produces sharper, less clustered scores and its Supplemental metrics (especially Safety) matter for industrial and IoT systems. In practice you'll encounter v3.1 everywhere for years because NVD's historical corpus is scored with it, so vulnerability-management tooling must read both. The good news: the mental model — exploitability × impact, adjusted for threat and environment — carries straight across.
How organizations use CVSS in practice
CVSS drives three concrete decisions in a mature program:
- Prioritization and SLAs. Critical and High findings jump the queue; the severity band sets the remediation deadline (see the SLA table above).
- Compliance. PCI-DSS, HIPAA-aligned programs, and many contractual requirements reference CVSS thresholds when defining "must-fix" vulnerabilities.
- Risk aggregation. CVSS feeds broader risk models alongside asset criticality and threat intelligence — it is an input, never the whole answer.
The limitations you have to design around
CVSS is a severity model, not a risk model, and treating the Base score as risk is the single most common mistake.
- No business context. A Base score knows nothing about which of your systems is a crown-jewel database and which is a throwaway VM.
- Static by design. The Base score of a five-year-old, mass-exploited bug looks identical to a fresh one with no known exploit — unless you apply Threat/Temporal metrics.
- Exploit likelihood is missing from the Base score. Pair CVSS with EPSS (the Exploit Prediction Scoring System) and the CISA KEV catalog to know what is actually being exploited right now.
- Scoring is judgment-laden. Two analysts can produce different vectors for the same bug; always publish the vector string so the reasoning is auditable.
The practical fix: use CVSS to establish intrinsic severity, then layer EPSS, KEV, and your own asset criticality on top before you decide patch order. That is how a Medium on an internet-facing payment gateway correctly beats a Critical on an air-gapped lab box.
Conclusion
CVSS gives the industry a shared, reproducible language for vulnerability severity: eight Base metrics compress into a single 0.0–10.0 number and a severity band, and the vector string makes every score auditable. It is maintained by FIRST.org, applied at scale by NIST's NVD, and evolving through v4.0 toward better fidelity for real-world exploitability and safety. Use the calculator above to build intuition for how the dials move the number — then remember the discipline the score can't supply for you: CVSS ranks severity, but risk is severity plus exploitability plus what the asset is worth to your business.