The CVSS (Common Vulnerability Scoring System), maintained by FIRST, is the common language for describing the severity of a vulnerability. Version 4.0 was published on 1 November 2023 and changed a lot: new metrics, a whole new group, a different way of calculating and a nomenclature that states which metrics were used.
In 48,000 CVEs a year we showed why CVSS alone prioritises poorly. This is the companion piece: how to read the score correctly and how to use the parts of CVSS that most organisations ignore.
Severity, not risk
The specification is clear about the role of CVSS: it describes the characteristics and severity of vulnerabilities, and organisations may use it as an input to a management process that also considers factors outside CVSS. It does not say what a flaw costs or how likely it is to become an incident in your company.
The qualitative scale is unchanged from the previous version:
| Rating | Score |
|---|---|
| None | 0.0 |
| Low | 0.1 – 3.9 |
| Medium | 4.0 – 6.9 |
| High | 7.0 – 8.9 |
| Critical | 9.0 – 10.0 |
The four metric groups
| Group | What it measures | Who fills it in | Changes the score? |
|---|---|---|---|
| Base | Intrinsic characteristics of the flaw: how it is attacked and what it compromises. Constant over time and across environments | Vendor or bulletin analyst | Yes |
| Threat | Exploit maturity: attacked, public proof of concept, or unreported | The software's user, with threat intelligence | Yes |
| Environmental | How important the asset is for confidentiality, integrity and availability, and the effect of your controls | The software's user | Yes |
| Supplemental | Extra information: safety impact, automatable attack, recovery, value density, response effort, provider urgency | Vendor | No |
To make clear what was filled in, version 4.0 introduced a nomenclature: CVSS-B (Base only), CVSS-BT (Base and Threat), CVSS-BE (Base and Environmental) and CVSS-BTE (all three). The specification recommends using it wherever a numerical score is displayed.
What changed from CVSS 3.1
- Attack Requirements (AT), a new metric. It separates from attack complexity the conditions of the vulnerable system itself that must exist for the attack to work, such as a specific configuration or a race condition.
- User interaction in three levels. None, passive or active, instead of just yes or no.
- No more "Scope". Instead, impact is described in two sets: on the vulnerable system (VC, VI, VA) and on subsequent systems (SC, SI, SA).
- Temporal became Threat. The group kept a single metric, Exploit Maturity.
- Supplemental group. New, and deliberately outside the calculation.
- A different calculation. Instead of a formula, the roughly 15 million possible vectors were grouped into 270 sets of comparable severity, ordered on the basis of expert comparisons. The score comes from a reference table plus interpolation.
How to read the vector
The score is only the summary. What describes the flaw is the vector. An example:
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Reading left to right: attackable over the network (AV:N), with low complexity (AC:L), no special requirements on the target (AT:N), no privileges (PR:N) and no user interaction (UI:N). Impact on the vulnerable system is high for confidentiality, integrity and availability, with no impact on subsequent systems. The score is 9.3, critical.
The same flaw, four scores
The detail almost nobody notices: when the Threat and Environmental groups are not filled in, the specification assumes the worst case. An empty Exploit Maturity is treated as "attacked", and empty asset security requirements are treated as "high". The published Base score is therefore already the most pessimistic scenario.
See what happens to the vector above when your organisation fills in what it knows:
| What was filled in | Score | Rating |
|---|---|---|
| Base only (CVSS-B) | 9.3 | Critical |
| + public proof of concept, no reported attacks (E:P) | 8.9 | High |
| + no known exploitation (E:U) | 8.1 | High |
| + no known exploitation, on a low-importance system (E:U, CR:L, IR:L, AR:L) | 6.5 | Medium |
The flaw is the same in all four rows. What changes is how much the organisation knows about the threat and about its own environment. That is why a treatment queue built only on Base scores looks too urgent: every row is at the worst case.
In practice: five rules
- Label the score. In reports and dashboards, write CVSS-B or CVSS-BTE. A Base 9.3 and a 9.3 with threat and environment filled in do not say the same thing.
- Fill in Threat automatically. CISA's KEV catalog indicates confirmed exploitation; EPSS and threat intelligence help separate a proof of concept from no reports at all.
- Fill in Environmental by asset class, not by flaw. Define confidentiality, integrity and availability requirements once for groups of assets — those supporting critical processes as high, lab and test as low — and apply them to every flaw in that group.
- Use Supplemental as a tie-breaker. "Automatable: Yes" flags a flaw that can be exploited at scale; "Safety" is decisive in industrial and healthcare environments.
- Do not mix versions in the same ranking. During the transition, many sources still publish 3.1 scores. The calculation is different; treat the version as part of the data.
Once that is done, the score stops being a generic vendor label and starts saying something about your organisation. To reach a real priority it still needs to be combined with exposure and business impact — which is the job of a well-built risk score.
Sources consulted on 4 October 2026: CVSS v4.0 Specification Document, by FIRST, including the qualitative scale and version history; the CVSS v4.0 reference calculator published by FIRST, used to calculate the example scores. Check the official specification before defining your scoring policy.