What is CVSS?
CVSS describes a vulnerability precisely enough that the description produces a number everyone computes the same way. You assign a value to each metric, concatenate them into a vector string, and the formula turns the vector into a score from 0.0 to 10.0 with a severity band. It is maintained by FIRST, the Forum of Incident Response and Security Teams, and NVD, vendor advisories and scanners use it to communicate severity.
CVSS has three metric groups:
- Base: the intrinsic properties of the vulnerability that do not change over time or between deployments. This is the score that gets published.
- Temporal (v3.1) / Threat (v4.0): adjustments for the state of exploitation and remediation right now. Optional, and can only lower the score.
- Environmental: a re-weighting for one specific deployment, set by the organization running the affected system.
You can compute and share any of these in a free CVSS calculator, which implements the CVSS v3.1 formulas and runs entirely in the browser.
A real vector, decomposed
Take CVE-2023-4966, "Citrix Bleed", a sensitive-information disclosure in NetScaler ADC and Gateway. Citrix scored it with this v3.1 base vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:LRead metric by metric:
| Metric | Value | Meaning |
|---|---|---|
| AV (Attack Vector) | Network | Exploitable over the internet |
| AC (Attack Complexity) | Low | No special conditions have to line up |
| PR (Privileges Required) | None | No authentication needed |
| UI (User Interaction) | None | No victim has to do anything |
| S (Scope) | Unchanged | Impact stays within the vulnerable component |
| C (Confidentiality) | High | Serious data disclosure, including session tokens |
| I (Integrity) | High | Attacker can alter data |
| A (Availability) | Low | Limited effect on uptime |
That vector scores 9.4, Critical. The base score combines two sub-scores: an exploitability sub-score of 3.9 (from AV, AC, PR, UI) and an impact sub-score of 5.5 (from C, I, A), rounded up. NVD later assigned a more conservative vector for the same CVE, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, scoring 7.5, rating only confidentiality as impacted. Two analysts scoring one flaw differently is normal, and the vector shows exactly where they disagreed: integrity and availability.
Base vs threat vs environmental
The base score answers "how bad is this vulnerability in the abstract". The other two groups answer questions the base score cannot.
Threat / Temporal adds what is true today. In v3.1 the temporal metrics are Exploit Code Maturity, Remediation Level and Report Confidence. Setting Citrix Bleed to Exploit Code Maturity: High, Remediation Level: Official Fix, Report Confidence: Confirmed gives:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L/E:H/RL:O/RC:Cwhich lowers the temporal score to 9.0. Temporal metrics never raise a score.
Environmental lets the operator override the base metrics for their deployment and weight confidentiality, integrity and availability by how much each matters on the affected asset. On a system where confidentiality is critical, setting Confidentiality Requirement: High raises the environmental score above the base. On a system that is not internet-facing, setting Modified Attack Vector to a lower reach lowers it. These metrics are meant to be set by the end-user organization, not the publisher.
How does CVSS v4.0 differ from v3.1?
FIRST published CVSS v4.0 on November 1, 2023. The changes are structural, not cosmetic, and the two versions are not interchangeable.
- Scope is gone. v3.1's single Scope flag is replaced by separate impact metrics for the Vulnerable System (VC, VI, VA) and Subsequent Systems (SC, SI, SA).
- Attack Requirements (AT) is new, splitting out conditions that v3.1 folded into Attack Complexity.
- User Interaction gains a third value: None, Passive, or Active.
- Temporal became Threat, keeping only Exploit Maturity and dropping Remediation Level and Report Confidence.
- New nomenclature states which groups were used: CVSS-B (base only), CVSS-BT (base + threat), CVSS-BE (base + environmental), CVSS-BTE (all three).
- Supplemental metrics (Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency) convey extra context without changing the score.
- Scoring works differently. v3.1 applies a published formula. v4.0 maps a vector to a MacroVector and looks up a score from expert-calibrated data, so there is no closed-form equation.
Because the metrics and the math both changed, a v3.1 score and a v4.0 score for the same vulnerability are not comparable. Match whichever version the record you are reading uses. v3.1 still covers the overwhelming majority of existing advisories and scanner output, which is why most calculators, including the one linked above, implement it.
The most common misuse: treating the base score as risk
The base score measures severity, not risk. The v4.0 user guide says it directly: base scores "should not be used alone to assess risk". Severity is a property of the vulnerability; risk depends on your environment, which the base score knows nothing about.
The practical failure is a patch queue sorted by base score alone. A 9.8 in a dependency whose vulnerable function your code never calls can matter less than a 6.1 in the authentication path in front of customer data. To turn severity into a priority, combine the CVSS base score with two things it omits: whether the flaw is actually being exploited, from the KEV catalog and the Exploit Prediction Scoring System, and whether the vulnerable code is reachable and exposed in your deployment, which is what testing establishes.
[ Sources ]
Written by Parameter · Last reviewed
