CVSS v4, released by FIRST in general availability on November 1, 2023, is the latest version of the Common Vulnerability Scoring System, and it reworks the base metrics to fix long-standing complaints that v3.1 scores were coarse and inconsistent. If you triage CVEs, the practical takeaways are: the Scope metric is gone, two new dimensions were added, and the way you communicate a score changed. This guide walks through what moved and how to actually apply it.
Why a new version was needed
CVSS v3.1 had been the industry default for years, but it accumulated well-known pain points. The Scope metric confused nearly everyone; vendors scored the same vulnerability differently because there was no shared intuition for when scope "changed." Temporal and environmental metrics were rarely used, so almost every published score was a Base score treated as absolute truth, even though FIRST always intended Base to be only the starting point. And User Interaction was a blunt yes/no that lumped very different scenarios together.
CVSS v4 addresses those directly. The headline is that it tries to make the numbers reflect exploitability and impact more faithfully, while making the extra metric groups easier to reach for.
The Scope metric is gone
The single biggest change is the retirement of the Scope (S) metric. In v3.1, Scope tried to capture whether a vulnerability in one component could affect resources beyond its security authority. In practice, scoring it consistently proved difficult, and it drove a lot of the disagreement between vendors.
CVSS v4 replaces it with two explicit impact sets. Instead of one Confidentiality/Integrity/Availability triad plus a Scope flag, you now score impact on the Vulnerable System (VC, VI, VA) and separately on Subsequent Systems (SC, SI, SA). This makes the "does it spread" question concrete: you rate the blast radius on downstream systems directly rather than through an abstract flag.
New metric: Attack Requirements
CVSS v4 adds an Attack Requirements (AT) base metric. It sits alongside Attack Vector and captures prerequisite conditions an attacker needs beyond simply reaching the target.
AT:N(None) means no special conditions are required; the attack works reliably.AT:P(Present) means exploitation depends on a specific deployment configuration, a race condition, or some other precondition that is not always met.
This separates "how do you reach the target" (Attack Vector) from "what has to be true for the exploit to land" (Attack Requirements). A race-condition bug that only fires under load now scores differently from one that fires every time, which is a genuine improvement in fidelity.
User Interaction got more granular
In v3.1, User Interaction was binary: None or Required. CVSS v4 expands the "required" case into two values:
- Passive (P): the victim performs limited, unintentional interaction — for example, viewing a page that silently triggers the flaw.
- Active (A): the victim must take a deliberate action, such as importing a file or clicking through a specific workflow.
The distinction matters for prioritization because a bug requiring only passive interaction is meaningfully easier to exploit at scale than one requiring a targeted, active step.
The scoring nomenclature changed
CVSS v4 also cleaned up how scores are named so nobody mistakes a partial score for the full picture. You now see suffixes:
- CVSS-B — Base metrics only.
- CVSS-BT — Base + Threat (Threat replaces the old Temporal group).
- CVSS-BE — Base + Environmental.
- CVSS-BTE — Base + Threat + Environmental, the most complete assessment.
The intent is to nudge teams away from treating the raw Base score as gospel. A CVSS-B of 9.8 tells you the theoretical worst case; a CVSS-BTE score adjusted for your environment tells you what it means for you.
A v4 vector string looks like this:
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
Note the AT:N element and the split VC/VI/VA (vulnerable system) versus SC/SI/SA (subsequent systems) that did not exist in v3.1.
How to use CVSS v4 in real triage
A score is an input to prioritization, not the decision itself. The most useful habits carry over from v3.1 and get sharper in v4:
Do not stop at the Base score. The whole point of the new nomenclature is to remind you that CVSS-B ignores whether an exploit exists in the wild and whether the affected asset even matters in your environment. Layer Threat and Environmental data on top.
Combine CVSS with exploit intelligence. CVSS measures severity, not likelihood of attack. Pairing it with data like CISA KEV or EPSS-style exploit-probability signals separates the theoretically severe from the actively dangerous.
Recompute for your context. A VA:H availability impact on a batch job you run monthly is not the same emergency as the same score on a customer-facing API. Environmental metrics exist so you can say so.
In practice, most CVEs are published with a CVSS-B score, and both v3.1 and v4 scores coexist in advisories today, because the ecosystem is mid-migration. Vulnerability management tooling has to speak both. An SCA platform such as Safeguard surfaces the vendor-assigned score alongside exploit signals so you are not prioritizing on the base number alone; you can read more about turning scores into action in our vulnerability prioritization guide. The goal is always the same: spend remediation effort where real risk lives.
FAQ
When was CVSS v4 released?
FIRST published CVSS v4.0 in general availability on November 1, 2023. Adoption has been gradual, so you will encounter both v3.1 and v4.0 scores in advisories for some time as the ecosystem transitions.
Is a CVSS v4 score comparable to a v3.1 score?
The severity bands (None, Low, Medium, High, Critical) use the same numeric ranges, so a 9.0 is Critical in both. But because the underlying metrics changed, the same vulnerability can produce a different number across versions. Do not assume a v4 score equals its v3.1 counterpart; note which version produced any score you record.
What replaced the Scope metric in CVSS v4?
Scope was removed and replaced by explicit dual impact metrics: impact on the Vulnerable System (VC, VI, VA) and impact on Subsequent Systems (SC, SI, SA). This makes the "does the impact spread beyond the vulnerable component" question concrete rather than an abstract flag.
Should I re-score all my old vulnerabilities in v4?
Generally no. Re-scoring your entire backlog is rarely worth the effort. Use the version an advisory provides, adopt v4 for new assessments, and focus energy on environmental context and exploit intelligence, which move prioritization far more than the version number does.