CVSS v3.1 vs v4.0: what changes and how to score it right
CVSS v4.0 (November 2023) is not a cosmetic patch over v3.1: it changes how impact is modeled, reworks the metric groups and —most importantly— hammers home something people had ignored for years: the base score is not the risk. If you're coming from v3.1, these are the changes that actually matter and the mistakes people keep making when scoring.
1. Impact now looks at two systems, not a "scope"
In v3.1 the infamous Scope (S:U / S:C) was the least-understood metric: it tried to capture "does the flaw jump to another component?" with a single bit, and half the world set it wrong. v4.0 drops it and replaces it with explicit impact on two separate systems:
- Vulnerable System:
VC/VI/VA(confidentiality, integrity, availability of the affected component itself). - Subsequent Systems:
SC/SI/SA(what lies beyond: other machines, the network, the victim's browser…).
An XSS, for instance, barely touches the vulnerable server but lands squarely on the subsequent system (the user's browser). Now that's expressible without acrobatics.
2. Complexity (AC) and Attack Requirements (AT) split apart
In v3.1, AC:H mixed two different things: "you must defeat a mitigation" and "it depends on a race condition / MITM position / specific config". v4.0 separates them:
- AC — Attack Complexity: does the attacker have to actively defeat a defense (ASLR, canaries, validation)?
- AT — Attack Requirements: are there deployment or execution conditions outside their control (winning a race, being on the network path, a non-default config)?
AC:H what is now AT:P. If the obstacle isn't a security defense but the environment, it's AT, not AC.3. User Interaction is no longer a yes/no
v3.1 only had "None / Required". v4.0 distinguishes None / Passive / Active: the victim doing nothing, unknowingly opening a document (passive), or following a specific sequence of steps (active) are not the same thing. It sharpens how realistic the vector is.
4. Temporal becomes "Threat" and slims down
v3.1's Temporal group had three metrics; two aged badly (Remediation Level and Report Confidence). v4.0 keeps a single threat metric:
- E — Exploit Maturity:
Attacked(already exploited, or automated),PoC(proof of concept only),Unreported(no known exploitation).X= "not defined" and assumes the worst case, like the base.
5. Environmental: your context, with "Safety" for OT/ICS
The environmental group still carries the business C/I/A requirements (how much does losing each one hurt?) and the modified base metrics for your specific deployment. What's new: MSI and MSA accept the value Safety — meant for environments where an integrity/availability failure can affect human lives (industrial, medical, automotive).
6. Supplemental: context that does NOT change the score
v4.0 adds a purely informational Supplemental group. It doesn't touch the score; it helps prioritize and lets the vendor communicate nuance:
- Safety, Automatable (can recon→exploitation be automated, worm-style?), Recovery, Value Density (diffuse vs concentrated resources), Response Effort and Provider Urgency (Clear/Green/Amber/Red).
7. There's no formula you can do by hand anymore
v3.1 had closed-form equations: with patience you could work it out on paper. v4.0 scores via a MacroVector (it groups combinations and interpolates distances against a reference table). In practice: you need a calculator; there's no equation to punch in.
The score's name depends on what you include
And this is what gets ignored most. FIRST names the score after the groups you supply:
CVSS-B Base only → intrinsic severity
CVSS-BT Base + Threat → + exploit maturity
CVSS-BE Base + Environment → + your context
CVSS-BTE everything → the full picture
Publishing the "bare" CVSS-B (that headline 9.8) and treating it as risk is the core mistake: the base measures intrinsic worst-case severity, not the odds that it hits you.
9.8 can drop a lot once you say "no known exploitation" and "this sits on an internal network with no critical data". Scoring only the base and deciding with it inflates the panic.From score to decision
Scoring well is the first step, not the last. Once you have a realistic CVSS, to prioritize patches you need more: the real probability of exploitation (EPSS), whether it's exploited in the wild (CISA's KEV) and your exposure. I cover it in "Which CVE to patch first".
Checklist to score without slipping
- ✅ Impact on the vulnerable system, the subsequent ones, or both? (goodbye Scope bit)
- ✅ Is the obstacle a defense (AC) or an environment condition (AT)?
- ✅ User Interaction: None / Passive / Active, not yes/no
- ✅ Are you publishing
CVSS-Band calling it "risk"? It isn't - ✅ Add Threat and Environment before deciding;
X= worst case - ✅ To truly prioritize: CVSS + EPSS + KEV + exposure
v4.0 isn't harder, it's more honest: it forces you to state what you're measuring. And almost always, that headline 9.8 was a base with no context.