A vulnerability queue now holds two kinds of CVSS score. Some CVEs carry a v3.1 vector, some a v4.0 vector, some both, and a record scored only under v3.1 keeps that score unless someone rescores it. The two versions share a 0 to 10 scale and similar severity labels, which makes them look interchangeable. They are not, and a queue that sorts them in one column without saying which is which is ranking two different measurements.
What changed in the metric groups
The CVSS v3.1 specification states: “CVSS is composed of three metric groups: Base, Temporal, and Environmental.” The CVSS v4.0 specification states: “CVSS is composed of four metric groups: Base, Threat, Environmental, and Supplemental.”
The v4.0 User Guide summarizes one of the changes in a single line: “Temporal Metric Group renamed to Threat Metric Group.” The Threat group carries the information that changes over time, chiefly exploit maturity. The Supplemental group is new and adds context without moving the number; the specification says that no Supplemental metric “will, within its specification, have any impact on the final CVSS score.”
What changed in the Base metrics
Three Base changes matter most when reading a v4.0 vector next to a v3.1 one.
Attack Requirements. v4.0 adds Attack Requirements (AT), which the specification says “captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack.” Attack Complexity remains, but now covers what an attacker must do to get past defensive technologies. Conditions outside the attacker’s control, such as winning a race window or holding an on-path network position, belong to AT.
User Interaction. v3.1 offers None or Required. v4.0 splits the second value into Passive and Active, separating limited, involuntary interaction from a user taking specific, conscious steps.
Scope. v3.1 used a Scope metric that “captures whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope.” The User Guide states that in v4.0 “The concept of Scope has been replaced with the concepts of a vulnerable system (VC, VI, VA) and a subsequent system (SC, SI, SA).” Instead of one flag changing the calculation, impact is recorded separately for the vulnerable system and for systems beyond it.
Naming the score
v4.0 introduces names that say which groups produced a number: CVSS-B for Base only, CVSS-BT for Base and Threat, CVSS-BE for Base and Environmental, and CVSS-BTE for all three. The specification says this nomenclature “should be used wherever a numerical CVSS value is displayed or communicated.” The reason is given in the User Guide: “Numerical CVSS Scores have very different meanings based on the metrics used to calculate them.”
The same guide notes that assessment providers, including the NVD, “typically provide only the Base Scores enumerated as CVSS-B.” A score taken from a public feed is usually a Base score, but not always: read the supplied vector and nomenclature before assuming which groups produced the number.
Why the two Base scores do not compare
The v4.0 metrics are different, and so is the arithmetic. The CVSS v4.0 FAQ explains that the v4.0 number comes from expert ranking rather than the v3.x algebraic formula, and concludes: “Naturally, some scores will be different between the two versions of the standard.”
A v3.1 8.1 and a v4.0 8.7 for the same CVE do not mean the vulnerability became more severe. They are two assessments, under two specifications, possibly by two different scorers. Converting one into the other by mapping metrics is also unreliable: Attack Requirements, the Passive and Active split and the subsequent-system impacts have no exact v3.1 counterpart, so any translation has to guess.
Sources differ too. A CVE record may carry a score from the CNA that assigned it, from the NVD, or both, in either version, and a scanner’s plugin data may carry yet another. A CVE scored only under v3.1 stays that way until someone assesses it again, so v3.1 scores will remain in queues alongside v4.0.
Severity, not risk
None of this changes what a Base score is for. The User Guide has a section titled “CVSS Base Score (CVSS-B) Measures Severity, not Risk,” and the FAQ is blunter: “CVSS-B Base scores are not risk, and should not be used alone for patch prioritization.” The specification expects consumers to “enrich the Base metrics with Threat and Environmental metric values specific to their use of the vulnerable system.” A more refined Base score is still a Base score. How severity combines with exploitation signals and asset evidence is covered in When KEV, EPSS and asset context disagree.
A hypothetical comparison
Take one hypothetical CVE in a web framework, found on two assets. On the first, an internet-facing customer portal, the record shows a v3.1 Base score of 8.1 from the scanner’s plugin data. On the second, an isolated build server in a lab segment, the record shows a CVSS-B of 8.7 from the CNA’s v4.0 assessment.
Sorted by a single score column, the lab server comes first. Yet the vulnerability is the same, and so are its KEV status and EPSS probability. The scores differ because they come from two versions and two scorers, so the gap says nothing about either asset. What does differ is the asset: one is reachable from the internet and supports a customer system, the other is not. The portal finding should lead, and the reason should be written down: “Internet-facing; customer portal; same CVE as lab finding; score difference is version and source, not severity.”
Operating with mixed versions
Keep the full vector string with every score, not just the number. The v4.0 vector “begins with CVSS:4.0 rather than CVSS:3.1,” so the vector records the version, and it lets an analyst see which metrics drove the result.
Label the score by version and nomenclature wherever it is displayed: “v3.1 Base 8.1” or “CVSS-B 8.7 (v4.0)”. When both versions exist for one CVE, keep both with their source rather than choosing one silently.
Apply Threat and Environmental metrics where the team actually knows the values, and record that it did, so a CVSS-BTE is never mistaken for a published CVSS-B. Exploit maturity in the Threat group overlaps with CISA KEV and EPSS; when they are available, the direct evidence and the current forecast are the better inputs. Model versions matter there as well, as covered in EPSS v5: what changed.
In practice
- Store CVSS version, vector string, score and source for every finding; derive the version from the vector prefix rather than assuming it.
- Never sort v3.1 and v4.0 scores in one unlabelled column; show the version beside every number, and use CVSS-B, CVSS-BT, CVSS-BE or CVSS-BTE for v4.0 values.
- Do not convert a v3.1 vector into a v4.0 score, or the reverse; keep the score each source published.
- Add Threat and Environmental values only where they are known, and record when a score has been adjusted locally.
- Set urgency from CISA KEV, EPSS, asset exposure and business impact, with CVSS severity as one input, and record the reasons.
Sectie’s Exposure & Vulnerability Management product shows CVSS version and vector next to each finding and ranks with CISA KEV, EPSS, asset context and operational state, with the reasons visible next to the priority.
