CVSS 4.0 Explained: What Changed, New Metrics, and How to Use the New Scoring System

CVSS 4.0 introduces changes across every metric group. Understanding which changes are structural versus cosmetic is essential for teams evaluating whether and how to transition.

Base metric changes:

The most structurally significant changes are:

Attack Requirements (AT): A new base metric that captures prerequisites for exploitation beyond the attack vector. AT:N (None) means no special conditions are required; AT:P (Present) means that specific deployment configuration, race condition, or other prerequisite must be present. This separates general attack feasibility (captured by Attack Complexity) from environmental prerequisites, providing more precise scoring for vulnerabilities that require specific configurations to exploit.

User Interaction (UI) expansion: CVSS 3.1 had only two values: None and Required. CVSS 4.0 expands to three: None, Passive (the victim performs a routine action like opening a file or visiting a page, without specific social engineering), and Active (the victim must take a non-routine action that would typically require social engineering). This distinction matters for phishing-delivered exploits versus drive-by exploits.

Scope metric removal: The binary Scope: Unchanged/Changed metric from CVSS 3.1 is replaced by the dual-impact model (Vulnerable System + Subsequent System impact), which provides six CIA metrics instead of three and eliminates the ambiguity in how Scope was applied.

Metric group changes:

• Temporal group renamed to Threat group, reduced from three metrics (Exploit Code Maturity, Remediation Level, Report Confidence) to one metric (Exploit Maturity: E:A/P/U)
• New Supplemental metric group added (Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency)
• Supplemental metrics do NOT modify the CVSS score; they provide additional context for consumers

Nomenclature changes:

• CVSS 4.0 defines four official score types: CVSS-B (Base only), CVSS-BT (Base + Threat), CVSS-BE (Base + Environmental), and CVSS-BTE (Base + Threat + Environmental)
• Users are encouraged to report which score type they are publishing alongside the score value

The two most practically impactful Base metric changes in CVSS 4.0 are the addition of Attack Requirements and the expansion of User Interaction from two to three values.

Attack Requirements (AT):

AT distinguishes between two types of conditions that affect exploitability beyond the attack vector:

• AT:N (None): No specific conditions beyond the attack vector are required. The vulnerability is exploitable against any target running the vulnerable software from the specified attack vector. Most network-accessible vulnerabilities without specific configuration requirements are AT:N.

• AT:P (Present): Specific conditions must exist for exploitation to succeed. Examples include: a specific non-default configuration option that exposes the vulnerability, a race condition that requires the target system to be in a specific transient state, or a deployment pattern (such as running behind a load balancer with session stickiness) that enables the attack.

The scoring impact of AT is significant: AT:P reduces the Base score compared to AT:N for the same vulnerability, reflecting the reduced practical exploitability when prerequisites must be present.

Where AT:P is commonly applied:

• PHP deserialization vulnerabilities that are only exploitable when specific unserialize() functions are called with attacker-controlled input through a particular code path
• Race condition vulnerabilities in multi-threaded applications
• Vulnerabilities in optional modules or plugins that are not enabled by default
• Vulnerabilities that require a specific database schema or application data state

User Interaction (UI) three-value expansion:

• UI:N (None): No user action is required. The attacker can exploit the vulnerability purely through their own actions. Remote code execution via an unauthenticated network service is UI:N.

• UI:P (Passive): The victim must perform a routine action that they would naturally do during normal system use, without any social engineering. A victim opening a malicious file they received through normal email flows, viewing an attacker-crafted image, or browsing to a page that loads attacker-controlled content is UI:P. The key distinction is that the victim does not need to take any action they would not normally take.

• UI:A (Active): The victim must be convinced to take a non-routine action through social engineering. Clicking a link in a phishing email that they would not normally click, executing a file, or granting elevated permissions is UI:A. This explicitly models the social engineering component required for many drive-by and phishing-delivered exploits.

The practical implication: many CVEs that scored UI:R in CVSS 3.1 will now score either UI:P or UI:A in CVSS 4.0, and the distinction affects how organizations should prioritize based on their threat model and user population.

The CVSS 3.1 Temporal group contained three metrics: Exploit Code Maturity (E), Remediation Level (RL), and Report Confidence (RC). In practice, Remediation Level and Report Confidence were almost never set in published vulnerability data because they required active maintenance and were quickly outdated. CVSS 4.0 addresses this by:

1. Renaming the group from Temporal to Threat to reflect its actual purpose: capturing current real-world threat activity
2. Reducing the group to a single metric: Exploit Maturity (E)
3. Dropping Remediation Level and Report Confidence entirely

Exploit Maturity (E) values in CVSS 4.0:

• E:U (Unreported): No evidence of exploitation. No public proof-of-concept and no reports of active exploitation. This is the default value when no threat intelligence is available.

• E:P (Proof-of-Concept): Proof-of-concept code is publicly available but active exploitation in the wild has not been reported. This value applies when a functional exploit exists that demonstrates the vulnerability but has not been operationalized by attackers.

• E:A (Attacked): The vulnerability is being actively exploited in the wild. This value applies when credible threat intelligence sources (CISA KEV, GreyNoise, vendor incident reports, threat intelligence feeds) report active exploitation.

How Exploit Maturity affects scoring:

A CVSS 4.0 CVSS-B score uses the default E:U assumption. Setting E:A elevates the effective CVSS-BT score. The mathematical relationship is: a Critical CVSS-B vulnerability (9.0-10.0) with E:A scores at or near the same level; the same vulnerability with E:P scores slightly lower to reflect the theoretical versus realized threat. This scoring incentive is aligned with operational priority: known-exploited vulnerabilities should score highest.

Operationalizing Exploit Maturity:

Organizations can automate Exploit Maturity assignment by integrating threat intelligence sources with their vulnerability management pipeline:

• CISA Known Exploited Vulnerabilities (KEV) catalog: CVEs in KEV should be assigned E:A
• GreyNoise: Mass scanning activity for specific CVEs indicates E:A or E:P depending on context
• ExploitDB / Metasploit module availability: functional public exploits warrant E:P or E:A
• Vendor security advisories that note "exploited in the wild" warrant E:A

Automatic E:A assignment for all CVEs in CISA KEV and E:P for CVEs with Metasploit modules is a practical starting point that can be implemented with publicly available data sources.

The Supplemental metric group is CVSS 4.0's most novel addition. Unlike all other CVSS metric groups, Supplemental metrics do NOT affect the CVSS score. They provide contextual information that consumers can use to understand the vulnerability's characteristics beyond severity.

The six Supplemental metrics are:

Safety (S: N/P): Whether exploitation could affect physical safety. S:N means no physical safety impact. S:P (Present) means exploitation could directly or indirectly result in physical harm. This applies to vulnerabilities in industrial control systems (ICS), medical devices, automotive systems, and other cyber-physical environments where software compromise has physical consequences. CVSS 4.0 added Safety explicitly because the growth of OT/ICS and IoT systems has made physical safety impact a necessary dimension of vulnerability risk communication.

Automatable (AU: N/Y): Whether the full attack chain, from initial access through successful exploitation, can be automated at scale without human interaction per target. AU:Y (Yes) means the vulnerability can be incorporated into automated attack tools and used in mass exploitation campaigns. AU:N means automation is not feasible for some step in the attack chain. This metric directly maps to weaponization risk: AU:Y vulnerabilities are candidates for rapid mass exploitation and merit faster response timelines.

Recovery (R: A/U/I): Whether a victim system automatically recovers to a functional state after exploitation. R:A (Automatic) means the system recovers without operator intervention (transient denial of service). R:U (User) means recovery requires manual action but is achievable. R:I (Irrecoverable) means the system cannot be restored to a fully functional state without replacement or reimaging (ransomware, destructive malware, persistent firmware compromise).

Value Density (V: D/C): Whether the vulnerable deployment pattern is diffuse (many low-value targets, D) or concentrated (few high-value targets, C). A vulnerability in a widely deployed consumer application is V:D; a vulnerability in enterprise financial infrastructure is V:C. This helps consumers understand the economic incentive structure for attackers targeting the vulnerability.

Vulnerability Response Effort (RE: L/M/H): The effort required for a typical organization to remediate the vulnerability. RE:L (Low) means a simple patch is available and deployment is straightforward. RE:H (High) means remediation requires significant operational effort: complex workarounds, re-architecture, or manual remediation steps across many systems.

Provider Urgency (U: Clear/Green/Amber/Red): A qualitative urgency designation that vulnerability providers (vendors, CERTs) can set to communicate their overall assessment of the remediation urgency: Clear (no urgency), Green (low urgency), Amber (moderate urgency), or Red (act immediately). This is equivalent to TLP color codes applied to urgency rather than information sensitivity.

For vulnerability management programs, Automatable and Recovery are the two Supplemental metrics with the most immediate operational value. Combining Automatable:Yes with Exploit Maturity:Attacked and a high Base score identifies the vulnerabilities most likely to cause mass organizational impact in the near term.

To make CVSS 4.0 concrete, here is a step-by-step scoring exercise for CVE-2024-21413, a Microsoft Outlook remote code execution vulnerability that was exploited in the wild and added to CISA KEV.

Vulnerability summary: An attacker can send a specially crafted email containing a link to a UNC path. When the victim previews the email in Outlook, the Preview Pane automatically processes the link, triggering an NTLM credential leak and potential code execution without the victim clicking anything.

Step 1: Base metrics (attack pathway)

• Attack Vector (AV): Network (N) -- exploitation is initiated over the network via email
• Attack Complexity (AC): Low (L) -- no special technical conditions required beyond crafting the email
• Attack Requirements (AT): None (N) -- no special target configuration required; default Outlook installation is affected
• Privileges Required (PR): None (N) -- the attacker does not need any authentication
• User Interaction (UI): Passive (P) -- the victim must preview the email, which is a routine action when checking email; no social engineering required to get the victim to look at email

Step 2: Vulnerable System impact

• Vulnerable System Confidentiality (VC): High (H) -- NTLM credentials are leaked, which is a high-confidentiality impact on the vulnerable system
• Vulnerable System Integrity (VI): High (H) -- code execution is possible
• Vulnerable System Availability (VA): High (H) -- code execution can affect availability

Step 3: Subsequent System impact

• Subsequent System Confidentiality (SC): High (H) -- NTLM credentials can be used to authenticate to other systems (relay attacks)
• Subsequent System Integrity (SI): High (H) -- credential relay enables lateral movement and subsequent system compromise
• Subsequent System Availability (SA): High (H) -- access to subsequent systems can affect their availability

CVSS-B vector and score: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H CVSS-B Score: 9.3 (Critical)

Step 4: Threat metrics

CVE-2024-21413 was added to CISA KEV after active exploitation was observed. Exploit Maturity: Attacked (E:A)

CVSS-BT vector adds: /E:A CVSS-BT Score: 9.3 (the score does not change significantly from E:A because the base score is already at maximum)

Step 5: Supplemental metrics

• Automatable (AU): Yes (Y) -- the attack chain can be fully automated: generate malicious email, send to target, capture NTLM hash via Responder, relay hash
• Recovery (R): User (U) -- credential rotation is required but systems recover without replacement
• Provider Urgency (U): Red -- Microsoft rated this as critical with active exploitation

This walkthrough illustrates how CVSS 4.0 captures the full propagation risk (Subsequent System impact at High across all three CIA dimensions) that CVSS 3.1's Scope:Changed captured only qualitatively.

CVSS 4.0 does not solve the fundamental limitation of CVSS as a prioritization tool: CVSS scores severity, not risk. Risk requires context about your specific environment, asset criticality, compensating controls, and current threat activity, none of which are captured in a CVSS base score. But CVSS 4.0 does provide meaningful improvements in two areas: more precise severity communication and new supplemental context that operationally-focused programs can leverage.

What improves with CVSS 4.0:

The Subsequent System impact model provides a more precise signal about lateral movement and blast radius risk than the binary CVSS 3.1 Scope metric. A vulnerability with SC:H/SI:H/SA:H is a much clearer signal about multi-system risk than Scope:Changed in CVSS 3.1, which could mean anything from "one adjacent service is affected" to "the entire Active Directory forest is at risk."

The Automatable supplemental metric provides the weaponization risk signal that practitioners have historically had to derive from other sources. Combining Automatable:Yes with Exploit Maturity:Attacked directly identifies the vulnerabilities most likely to become mass exploitation events. This combination should trigger immediate escalation regardless of the specific CVSS-B score.

The simplified Threat group (E:A/P/U) is more practical for automation than the three-metric CVSS 3.1 Temporal group. A vulnerability management pipeline that automatically assigns E:A for CISA KEV entries is achievable with publicly available data; automatically and accurately scoring all three CVSS 3.1 Temporal metrics was impractical for most organizations.

What does not change:

CVSS 4.0 base scores alone are still insufficient for operational prioritization. The combination of CVSS-BTE (applying both Threat and Environmental metrics) with EPSS score, asset criticality, and exposure context remains the recommended approach. Organizations that are not applying Environmental metrics (CR, IR, AR requirements) are still producing context-free scores. CVSS 4.0 makes Environmental metrics slightly easier to apply with clearer guidance, but the organizational discipline to collect and maintain asset-level security requirements is still required.

Transition guidance:

1. Do not retroactively re-score your vulnerability backlog under CVSS 4.0. The engineering effort is not worth the scoring delta for historical vulnerabilities you have already prioritized.
2. For new CVEs, begin consuming CVSS 4.0 scores from NVD and vendor advisories alongside CVSS 3.1 scores. Use the NVD API's cvssMetricV40 field.
3. Update SLA thresholds carefully. A Critical CVSS 4.0 score does not map 1:1 to a Critical CVSS 3.1 score for the same CVE because the weighting changed.
4. Implement automated Exploit Maturity (E:A) assignment for CISA KEV entries and Automatable supplemental metric flagging as the first operational use of CVSS 4.0 data.