CVSS 4.0 Explained: Reading a Vector String Step by Step

Why bother learning the vector

Most people consume CVSS as a single number: 9.8, patch now; 5.3, maybe later. That number is the least informative part. The vector string behind it tells you why the score is what it is, which assumptions the scorer made, and whether those assumptions hold in your environment.

FIRST published CVSS 4.0 in November 2023, and 4.0 vectors now appear alongside 3.1 in advisories and vulnerability databases. The structure changed enough that reading a 4.0 vector with 3.1 habits leads to mistakes. This article walks through a vector one metric at a time.

Here is the example we will decode:

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

This is an unauthenticated, network-reachable flaw with high impact on the vulnerable system and none beyond it. It scores 9.3 (Critical) as a Base score. You can paste it into the CVSS calculator and toggle each metric as you read.

The four metric groups

CVSS 4.0 organises metrics into four groups:

Group Who fills it in Affects the score?
Base Vendor or CNA Yes
Threat Consumer, from threat intelligence Yes
Environmental Consumer, about their own deployment Yes
Supplemental Vendor or consumer No, context only

The vector always starts with CVSS:4.0/ and the eleven mandatory Base metrics in a fixed order. Optional metrics follow. Any metric left out is treated as X (Not Defined).

Base metrics, one by one

Base metrics describe the vulnerability itself, independent of time and of any particular environment. They split into exploitability metrics and two sets of impact metrics.

Exploitability

AV, Attack Vector (N Network, A Adjacent, L Local, P Physical). How close the attacker must be. Unchanged in spirit from 3.1.

AC, Attack Complexity (L Low, H High). In 4.0 this is narrowed to measurable actions the attacker must take to evade or defeat security mechanisms, such as defeating ASLR or obtaining a secret key. It no longer covers environmental preconditions; those moved to AT.

AT, Attack Requirements (N None, P Present). New in 4.0. Does a successful attack depend on deployment or execution conditions the attacker does not control? Examples: winning a race condition, a non-default configuration, needing to be in a man-in-the-middle position. In 3.1 these conditions were all lumped into AC.

PR, Privileges Required (N None, L Low, H High). The privileges the attacker needs before exploitation. Same values as 3.1.

UI, User Interaction (N None, P Passive, A Active). Now three values instead of two:

  • Passive: the user does something ordinary and limited, like viewing a crafted page or message, without consciously subverting protections.
  • Active: the user must take specific, deliberate actions, such as importing a file, dismissing a warning, or running something.

This distinction matters for phishing-delivered bugs, where "open the email preview" and "enable content after two warnings" are very different risks.

Vulnerable System impact

VC, VI, VA (H High, L Low, N None): confidentiality, integrity and availability impact on the vulnerable system, the component that contains the flaw.

Subsequent System impact

SC, SI, SA (H, L, N): impact on other systems beyond the vulnerable one. A cross-site scripting flaw in a web app may have low impact on the server (vulnerable system) and higher impact on the user's browser session (subsequent system). A hypervisor escape has its main impact on the host and other guests.

This pair of triplets replaces Scope. In 3.1, S:C (Scope Changed) was a binary switch that bumped the score and was inconsistently applied. In 4.0, you describe both impacts explicitly, which is more honest and easier to argue about.

Reading our example with this vocabulary: reachable over the network (AV:N), no special evasion needed (AC:L), no preconditions (AT:N), no account (PR:N), no user (UI:N), full compromise of the vulnerable system (VC:H/VI:H/VA:H), and no stated impact on other systems (SC:N/SI:N/SA:N).

Threat metrics: replacing Temporal

CVSS 3.1 had a Temporal group (Exploit Code Maturity, Remediation Level, Report Confidence) that almost nobody used. CVSS 4.0 replaces it with a Threat group containing a single metric:

E, Exploit Maturity:

Value Meaning
A Attacked Attacks are reported, or exploitation tools are publicly available
P POC A proof of concept is public, no known attacks
U Unreported No known PoC and no reported exploitation
X Not Defined Treated as Attacked (worst case)

Remediation Level and Report Confidence are gone.

The default matters: a Base score is effectively computed as if the vulnerability is being attacked. Adding E:P or E:U lowers the score; it never raises it. That is the mechanism by which 4.0 expects consumers to bring threat intelligence in, and it is why sources like CISA KEV and EPSS are natural inputs (more on that in CVSS, EPSS and KEV for prioritization).

Map your intel to E deliberately. A CVE on CISA KEV justifies E:A. A public PoC on a code-hosting site with no exploitation reports is E:P. "We have not looked" is not E:U; it is E:X, and it scores as Attacked.

Environmental metrics: your deployment

Environmental metrics let you adjust the score to your context.

Security Requirements: CR, IR, AR (H, M, L, X). How much confidentiality, integrity and availability of this asset matter to you. A payment database might be CR:H; a public marketing site CR:L.

Modified Base metrics: every Base metric has a modified counterpart prefixed with M: MAV, MAC, MAT, MPR, MUI, MVC, MVI, MVA, MSC, MSI, MSA. Use them when your deployment differs from the vendor's assumptions. If the vulnerable service is only reachable from a management VLAN, MAV:A or MAV:L may be justified; if a compensating control requires authentication in front of it, MPR:L.

MSI and MSA accept one extra value, S (Safety), for cases where the subsequent-system impact could cause physical harm. This is aimed at OT, medical and automotive contexts.

Supplemental metrics: context that does not change the score

Supplemental metrics are new in 4.0. They do not affect the numeric score. They exist so vendors and consumers can communicate context that a single number cannot.

Metric Values What it says
S Safety N Negligible, P Present Could exploitation cause physical harm?
AU Automatable N No, Y Yes Can an attacker automate the full kill chain (wormable-ish)?
R Recovery A Automatic, U User, I Irrecoverable How the system recovers after an attack
V Value Density D Diffuse, C Concentrated Resources gained per successful exploit
RE Vulnerability Response Effort L Low, M Moderate, H High How hard it is to respond or remediate
U Provider Urgency Clear, Green, Amber, Red The vendor's own urgency assessment

AU:Y is the one to watch in practice: an automatable, network-reachable, unauthenticated flaw is the profile of mass exploitation. Note that the Supplemental S (Safety) is a separate metric from the S value of MSI/MSA.

A fully specified vector might look 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/E:A/CR:H/IR:H/AR:M/MAV:A/AU:Y/R:U/V:C

Read it as: the vendor's Base assessment, exploitation in the wild, an asset where confidentiality and integrity matter most, a deployment only reachable from an adjacent network, and context flags saying the attack is automatable, recovery needs user action, and each compromise yields concentrated value.

CVSS-B, BT, BE, BTE: say which score you mean

One of the most useful changes in 4.0 is not a metric at all. It is nomenclature. A score should be labelled with the groups that went into it:

Label Metrics used
CVSS-B Base only
CVSS-BT Base + Threat
CVSS-BE Base + Environmental
CVSS-BTE Base + Threat + Environmental

The score in an advisory or a public database is almost always CVSS-B. It describes the vulnerability in the abstract, assuming worst-case threat. The specification is explicit that Base alone is not a risk score. If your patch SLAs key off "CVSS 9.0 or higher", you are prioritising on CVSS-B and ignoring the two groups designed for prioritisation.

How 4.0 computes the score

CVSS 3.1 used a formula. CVSS 4.0 does not. Instead, metric combinations are grouped into macrovectors (equivalence sets), each assigned a score from expert ranking, and the final score is interpolated within the macrovector based on how far the specific vector sits from the highest-severity vector in that group.

Practical consequences:

  • You cannot hand-compute a 4.0 score in a spreadsheet the way you could for 3.1. Use a calculator built on the reference implementation.
  • Small metric changes can move the score more or less than intuition from 3.1 suggests.
  • 3.1 and 4.0 scores are not comparable. A vulnerability can be 9.8 in 3.1 and a different number in 4.0 without either being wrong. Do not mix them in one SLA threshold without saying which version you mean.

The qualitative bands are unchanged: None 0.0, Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9, Critical 9.0 to 10.0.

Summary of changes from 3.1

Area CVSS 3.1 CVSS 4.0
Preconditions Inside AC Separate AT metric
User Interaction N / R N / P / A
Scope S:U / S:C Removed; VC/VI/VA and SC/SI/SA
Temporal group E, RL, RC Replaced by Threat: E only, X = Attacked
Environmental CR/IR/AR + modified base Same idea, plus S (Safety) for MSI/MSA
Supplemental None S, AU, R, V, RE, U (no score impact)
Scoring Formula Macrovectors and interpolation
Labels Not standardised CVSS-B, BT, BE, BTE

What to do Monday

  • Label every score you report as CVSS-B, BT, BE or BTE, and say whether it is 3.1 or 4.0.
  • Stop setting SLAs on CVSS-B alone. At minimum, fold in exploitation evidence (KEV, EPSS) through the Threat metric or alongside it. EPSS explained covers how to read the probability side.
  • Set Security Requirements for your top assets once, then reuse them for every vulnerability on those assets.
  • Read AT, UI and the SC/SI/SA triplet before arguing about a score. They are where most disagreements actually live.
  • Check AU when vendors provide it. Automatable plus network plus no auth deserves a faster lane.
  • Use the CVSS calculator to rescore with your Threat and Environmental values, and CVE search to pull the vendor vector as a starting point.

A CVSS number is a summary. The vector is the argument. Learn to read the argument, and the number starts to mean something.