Common Vulnerability Scoring System
The Common Vulnerability Scoring System (CVSS) is an open, standardized framework for assessing and communicating the principal characteristics and severity of software vulnerabilities in a consistent, numerical manner.[1] Developed and maintained by the Forum of Incident Response and Security Teams (FIRST), it produces scores ranging from 0.0 (no severity) to 10.0 (maximum severity), enabling security professionals, vendors, and organizations to prioritize remediation efforts based on vulnerability impact and exploitability.[2] Unlike risk assessments, CVSS focuses solely on vulnerability severity without considering broader contextual factors like asset value or threat landscape.[3] CVSS originated from a research initiative by the U.S. National Infrastructure Advisory Council (NIAC) between 2003 and 2004, with the initial version (v1.0) released in June 2005 to address the need for a common language in vulnerability reporting.[4] Subsequent iterations have refined its methodology: v2.0 launched in 2007 with updated temporal and environmental metrics; v3.0 arrived in June 2015, introducing scope as a key concept to better model chained exploits; v3.1 followed in June 2019 for minor clarifications and improved consistency; and the current v4.0 was published on November 1, 2023, emphasizing user interaction requirements and subsequent system impacts.[2] These evolutions reflect ongoing collaboration among industry, government, and academic stakeholders through the CVSS Special Interest Group (SIG), ensuring adaptability to emerging threats.[2] In its latest iteration (v4.0), CVSS organizes metrics into four groups: Base Metrics, which capture intrinsic vulnerability qualities such as attack vector (e.g., network, adjacent, local, physical), attack complexity, privileges required, user interaction, and impacts on confidentiality, integrity, and availability for both vulnerable and subsequent systems; Threat Metrics, assessing exploit maturity (e.g., unreported, proof-of-concept, actively exploited); Environmental Metrics, allowing customization for organizational security requirements and modified base factors; and Supplemental Metrics, providing non-scoring context like safety impact or recoverability.[1] The core Base Score is derived through a vector string representation (e.g., CVSS:4.0/AV:N/AC:L/...), using mathematical formulas involving exploitability and impact subscores, which are then adjusted by threat and environmental factors to yield temporal and environmental scores.[1] Qualitative severity ratings translate these numerical values into actionable categories: None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0).[3] Widely adopted by entities like the National Vulnerability Database (NVD) and vulnerability disclosure platforms, CVSS facilitates global interoperability in cybersecurity but requires users to supplement scores with site-specific risk analysis for comprehensive decision-making.[3] Calculators and vector parsers, available from FIRST and NIST, support practical implementation, while ongoing updates address limitations such as evolving attack surfaces in cloud and IoT environments.[1]Overview
Purpose and Framework
The Common Vulnerability Scoring System (CVSS) is an open, vendor-agnostic framework developed by the Forum of Incident Response and Security Teams (FIRST) to communicate the principal characteristics and severity of software vulnerabilities in a standardized manner.[2] It enables consistent assessment across organizations, facilitating prioritization of remediation efforts by providing a numerical score that reflects a vulnerability's potential impact and exploitability.[1] CVSS produces scores on a scale from 0 to 10, where 0 indicates no severity and 10 represents the maximum severity.[2] These numerical scores are mapped to qualitative severity ratings for easier interpretation: None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0).[1] In its current version (v4.0, released November 1, 2023), the framework organizes vulnerability assessment into four metric groups. The Base group captures the intrinsic qualities of a vulnerability that do not change over time, such as its exploitability and direct impact on affected systems.[2] The Threat group addresses factors that evolve, including the maturity of exploitation techniques and the availability of patches.[2] The Environmental group incorporates organization-specific modifiers, like the asset's importance or existing mitigations, to tailor the score to a particular context.[2] The Supplemental group provides additional non-scoring information for context.[1] The first public specification of CVSS, version 1.0, was released in February 2005, following initial research by a U.S. Department of Homeland Security working group.[5] It has since been maintained and updated by the CVSS Special Interest Group (SIG) under FIRST to adapt to evolving security needs.[2]Score Interpretation
The Common Vulnerability Scoring System (CVSS) provides a numerical score ranging from 0.0 to 10.0, which is interpreted into qualitative severity levels to communicate the potential impact of a vulnerability. These levels are defined as follows: 0.0 indicates None severity, 0.1–3.9 indicates Low, 4.0–6.9 indicates Medium, 7.0–8.9 indicates High, and 9.0–10.0 indicates Critical.[6] The use of these qualitative ratings is optional but widely adopted to standardize severity communication across organizations.[6] In vulnerability management, CVSS scores facilitate prioritization of remediation efforts, such as applying patches or mitigating risks, by allowing organizations to focus on higher-severity issues first.[3] For instance, the National Vulnerability Database (NVD), maintained by NIST, assigns CVSS Base scores to Common Vulnerabilities and Exposures (CVEs) during vulnerability assessments, enabling consistent risk evaluation and alerting.[3] These scores are also integrated into vulnerability scanners and management tools, where they inform automated prioritization and reporting workflows.[7] CVSS scores measure intrinsic severity based on vulnerability characteristics but do not constitute a complete risk assessment, as they exclude factors like the likelihood of exploitation or organizational context in isolation.[6] Users must supplement scores with additional analyses, such as Threat and Environmental metrics, to derive actionable risk insights.[7] Practical examples of score interpretation include enterprise policies that mandate immediate action for vulnerabilities scoring 7.0 or higher, such as a Base Score of 7.5 for a remotely exploitable flaw allowing unauthorized access, which might trigger urgent patching or system isolation.[7] Regulatory standards like PCI DSS require remediation of vulnerabilities with scores of 4.0 or greater to ensure compliance.[7] In alerts and reports, scores are often presented alongside vector strings for transparency, helping security teams quickly assess and respond to threats.[7]Historical Development
Origins and Initial Release
The Common Vulnerability Scoring System (CVSS) originated from efforts to address the fragmentation in vulnerability severity assessments during the early 2000s, when multiple incompatible scoring systems hindered effective communication among security stakeholders. Commissioned by the National Infrastructure Advisory Council (NIAC) in July 2003, the project sought to create an open, vendor-agnostic standard that would enable consistent evaluation of software vulnerabilities, facilitating better prioritization of patches, incident response, and accountability across vendors and organizations. This initiative responded directly to the lack of interoperability in existing systems, which often led to inconsistent reporting and varying interpretations of threat levels, ultimately impeding coordinated cybersecurity efforts.[8][9][10] The initial specification for CVSS was developed by a working group under the NIAC Vulnerability Disclosure Working Group, with primary authorship from members of the CERT Coordination Center (CERT/CC) and contributions from industry leaders including Cisco Systems, Symantec, Microsoft, Internet Security Systems, and others such as eBay, IBM, Qualys, and Symantec. Key pioneers involved in the design included David Ahmad, Gerhard Eschelbeck, Sasha Romanosky, Mike Schiffman, and Andrew Wright, who focused on establishing a universal framework to promote a common language for vulnerability severity. Although the National Institute of Standards and Technology (NIST) played a more prominent role in subsequent refinements, the foundational work emphasized simplicity, flexibility, and comprehensiveness to encourage broad adoption. The development process lacked extensive peer review initially, which later contributed to identified limitations.[8][10][9] CVSS version 1.0 was released in February 2005, introducing basic metrics for assessing vulnerability characteristics and producing a numerical score to standardize severity communication. Initially developed under NIAC, CVSS has been maintained by the Forum of Incident Response and Security Teams (FIRST.org) since April 2005, when NIAC selected FIRST as its custodian. In April 2005, shortly after v1.0's release, NIAC selected FIRST to serve as the ongoing custodian for CVSS development and maintenance. The system aimed to improve global vulnerability disclosure but saw limited adoption due to inaccuracies and inconsistencies in scoring that emerged during early use. These shortcomings prompted rapid iteration, with work on version 2.0 beginning in April 2005 to enhance accuracy and address real-world application issues through broader collaboration and testing.[11][12][9]Evolution Across Versions
The Common Vulnerability Scoring System (CVSS) has evolved through several versions since its initial formalization, with each iteration driven by feedback from stakeholders, including the CVSS Special Interest Group (SIG) for versions from v3.0 onward, challenges in widespread adoption, and the shifting landscape of cybersecurity threats, including the rise of cloud computing, Internet of Things (IoT) devices, and supply chain vulnerabilities.[2][13] CVSS version 2.0 was released in June 2007, marking a significant advancement by introducing temporal and environmental metric groups alongside the base metrics, which expanded the system's applicability beyond intrinsic vulnerability characteristics to include time-dependent factors and organizational context.[14] This version addressed early limitations in vulnerability assessment by providing a more dynamic framework, enabling users to adjust scores based on remediation status and deployment-specific impacts, thereby improving prioritization in diverse IT environments.[15] In June 2015, CVSS version 3.0 was launched to refine the base metrics for greater accuracy in evaluating contemporary threats, such as those in virtualized and cloud-based systems, responding to identified inconsistencies in v2.0 scoring practices observed after years of global adoption.[16] The update emphasized clearer definitions and a revised qualitative severity scale, driven by the need to better reflect the evolving complexity of attacks while maintaining backward compatibility where possible.[17] CVSS version 3.1 followed in June 2019 as a minor revision, focusing on clarifications and consistency enhancements without introducing new metrics or altering the core scoring formulas, primarily to resolve ambiguities in metric interpretations like attack vector and scope that had arisen from user feedback.[18] This iteration streamlined guidance on assumptions for scoring, such as attacker knowledge levels, to promote more defensible and uniform application across organizations.[7] The most recent major update, CVSS version 4.0, was released on November 1, 2023, representing a comprehensive overhaul motivated by SIG feedback on prior versions' shortcomings in handling nuanced impacts, automation needs, and emerging risks in operational technology (OT) and industrial control systems (ICS).[11] It introduced simplified threat metrics, enhanced impact subscores for vulnerable and subsequent systems, and a new supplemental metric group to better support automated analysis and safety considerations in modern threat landscapes like supply chain attacks.[13]Core Concepts
Metric Categories
The Common Vulnerability Scoring System (CVSS) organizes its assessment into four metric groups in version 4.0: Base, Threat, Environmental, and Supplemental. These groups capture different aspects of a vulnerability's severity, enabling a structured evaluation that balances universal characteristics with contextual factors. The Base group forms the foundation by focusing on inherent properties of the vulnerability, while the Threat and Environmental groups allow for adjustments based on evolving conditions and organizational specifics, respectively. Previous versions, such as v3.1, used Temporal Metrics instead of Threat Metrics and did not include Supplemental Metrics.[6][1] Base Metrics represent the fixed, intrinsic qualities of a vulnerability that remain constant over time and across different environments. They assess core attributes such as how easily the vulnerability can be exploited and the potential impact on affected systems, assuming a worst-case scenario without mitigations. This group produces the Base Score, a mandatory numerical value ranging from 0 to 10 that serves as the universal severity indicator for the vulnerability. For instance, subscores may evaluate exploitability through factors like attack vector, attack complexity, privileges required, and user interaction, and impact through effects on confidentiality, integrity, or availability for both the vulnerable system and subsequent systems.[1] Threat Metrics address time-dependent factors that can alter the vulnerability's severity as conditions evolve, such as the availability of exploit code or remediation efforts. These metrics modify the Base Score to generate a refined score, reflecting adjustments for real-world developments like the maturity of public exploits or the status of official fixes. By incorporating these elements, the Threat group provides a dynamic view of risk that decreases as defenses improve, though it remains independent of specific user environments. An example includes assessing the level of exploit maturity, which influences how readily an attack can be carried out.[1] Environmental Metrics enable customization of the severity assessment to fit an organization's unique context, such as the value of affected assets or existing security controls. They adjust the Base or Threat-refined Score to yield an Environmental Score, prioritizing impacts based on local requirements for confidentiality, integrity, or availability. This group allows users to modify base assumptions, for example, by accounting for collateral damage potential or the effectiveness of deployed safeguards. As a result, it tailors the overall score to reflect enterprise-specific risk rather than generic scenarios.[1] Supplemental Metrics provide additional non-scoring context, such as safety impact or recoverability, to aid in vulnerability prioritization without directly affecting the numerical scores. The Base Metrics are mandatory and conceptually consistent across CVSS versions, providing a stable core for comparisons, while Threat, Environmental, and Supplemental Metrics are optional enhancements that increase the system's relevance without altering the foundational assessment. These groups interrelate hierarchically: the Base Score is refined by Threat Metrics and further adjusted by Environmental Metrics, allowing for layered refinements. CVSS metrics function as qualitative inputs that are quantified through standardized formulas, and scores are shared via compact vector strings—such as "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N"—that encode all selected values for reproducibility and analysis.[1]General Scoring Principles
The Common Vulnerability Scoring System (CVSS) employs a structured methodology to aggregate vulnerability metrics into numerical scores, ensuring a standardized assessment of severity. At its core, the scoring process begins with the Base Score, which captures the intrinsic characteristics of a vulnerability that remain constant over time and across users. This foundational score is then optionally refined by Threat metrics to account for evolving threat factors, such as the maturity of available exploits, and by Environmental metrics to incorporate organization-specific contexts, like asset importance or mitigation controls.[1] A key feature of CVSS is its vector string notation, which provides a compact, machine-readable representation of the metric values used in scoring. For instance, a vector like "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N" encodes each metric's value (e.g., AV for Attack Vector set to Network) in a delimited format, facilitating easy sharing, reproduction, and verification of assessments across stakeholders. This notation ensures that the full assessment details accompany the score, promoting transparency and interoperability in vulnerability management.[1] CVSS metrics are primarily expressed in qualitative terms—such as "High," "Low," or "None"—which are systematically mapped to underlying numerical values as defined in the official specification documents. This conversion allows for quantitative score computation while maintaining accessibility for analysts without deep mathematical expertise, as the qualitative labels guide selections based on descriptive criteria. The resulting scores range from 0.0 to 10.0, with qualitative severity ratings (e.g., Low for 0.1-3.9, Critical for 9.0-10.0) providing interpretive bands.[1] To uphold consistency, CVSS is designed for reproducibility: identical metric inputs will always yield the same score, regardless of the assessor, through deterministic aggregation rules outlined in the specifications. This vendor-agnostic approach, supported by detailed guidance documents, enables non-experts to produce reliable evaluations while minimizing subjectivity. Over successive versions, these principles have been iteratively refined for greater precision—such as enhancing metric definitions and calibration methods—yet the fundamental logic of combining metric categories into layered scores has remained persistent, ensuring backward compatibility and broad adoption.[1]Version 2.0
Base Metrics
The Base Metrics in CVSS version 2.0 form the foundation of the scoring system, reflecting the inherent characteristics of a vulnerability that remain constant over time and across different environments. These metrics are divided into two primary subscores: Exploitability, which evaluates the ease and feasibility of exploiting the vulnerability, and Impact, which assesses the potential consequences on the affected system's confidentiality, integrity, and availability. The Base Score is then derived by combining these subscores, providing a numerical value from 0 to 10 that indicates severity without considering temporal or environmental factors. In v2.0, the scope of impact is implicitly limited to a single affected system, without an explicit metric for cross-system propagation.[19]Access Vector (AV)
The Access Vector metric measures the remoteness required to exploit the vulnerability, determining how distant an attacker must be from the vulnerable component. It uses three qualitative values: Local (L), which requires physical or logical proximity such as shell access (base value 0.395); Adjacent Network (A), which necessitates presence on the same local network segment like a broadcast domain (base value 0.646); and Network (N), allowing remote exploitation over the internet or other networks (base value 1.0). A Network access vector increases the Exploitability subscore, reflecting greater risk due to broader attacker reach.[19]Access Complexity (AC)
Access Complexity evaluates the conditions or barriers an attacker must overcome to exploit the vulnerability successfully, such as specific configurations or timing. The qualitative values are High (H), indicating specialized circumstances like rare race conditions (base value 0.35); Medium (M), involving somewhat uncommon setups like non-default configurations (base value 0.61); and Low (L), where no special conditions are needed and exploitation is straightforward (base value 0.71). Lower complexity values yield higher Exploitability scores, emphasizing vulnerabilities that are easier to trigger.[19]Authentication (AU)
The Authentication metric assesses the number of authentication mechanisms or instances an attacker must bypass to exploit the vulnerability. It includes None (N), requiring no credentials (base value 0.704); Single (S), needing one instance like a username-password pair (base value 0.56); and Multiple (M), demanding two or more authentications (base value 0.45). Vulnerabilities requiring no authentication contribute to higher Exploitability, as they lower the barrier for unauthorized access.[19]Confidentiality, Integrity, and Availability Impacts (C/I/A)
The Impact subscore is determined by three metrics aligned with the CIA triad: Confidentiality (C), Integrity (I), and Availability (A). Each uses the same qualitative values—None (N, base value 0.0), indicating no effect; Partial (P, base value 0.275), representing limited compromise such as partial data exposure or reduced performance; and Complete (C, base value 0.660), signifying total loss like full disclosure or system shutdown. For Confidentiality, Partial might involve access to sensitive but not all data, while Complete allows unrestricted exposure of all resources. Integrity impacts range from minor modifications in Partial cases to arbitrary alterations in Complete ones. Availability effects include degraded service in Partial scenarios versus complete denial in Complete ones. These values collectively quantify the vulnerability's potential harm.[19] The following table summarizes the base metric values:| Metric | Value | Description | Base Score |
|---|---|---|---|
| Access Vector (AV) | Local (L) | Local access required | 0.395 |
| Adjacent Network (A) | Same network segment | 0.646 | |
| Network (N) | Remote over network | 1.0 | |
| Access Complexity (AC) | High (H) | Specialized conditions | 0.35 |
| Medium (M) | Some specialized access | 0.61 | |
| Low (L) | No special conditions | 0.71 | |
| Authentication (AU) | Multiple (M) | Two or more instances | 0.45 |
| Single (S) | One instance required | 0.56 | |
| None (N) | No authentication | 0.704 | |
| Confidentiality/Integrity/Availability (C/I/A) | None (N) | No impact | 0.0 |
| Partial (P) | Limited impact | 0.275 | |
| Complete (C) | Total impact | 0.660 |
Base Score Calculation
The Base Score is computed in three steps using the base values from the metrics above. First, the Exploitability subscore is calculated as: \text{Exploitability} = 20 \times \text{AV} \times \text{AC} \times \text{AU} This is not rounded at this stage but contributes directly to the final score. Next, the Impact subscore is derived as: \text{Impact} = 10.41 \times (1 - (1 - \text{C}) \times (1 - \text{I}) \times (1 - \text{A})) The Impact value is capped at 10.0. Finally, the Base Score is obtained by: \text{Base Score} = \text{round to 1 [decimal](/page/Decimal)} \left( \left( (0.6 \times \text{[Impact](/page/Impact)}) + (0.4 \times \text{Exploitability}) - 1.5 \right) \times f(\text{[Impact](/page/Impact)}) \right) where f(\text{[Impact](/page/Impact)}) = 0 if Impact = 0, and f(\text{[Impact](/page/Impact)}) = 1.176 otherwise. The result is constrained between 0 and 10, with rounding applied to one decimal place. This weighted combination emphasizes impact while adjusting for exploitability, ensuring the score reflects both feasibility and consequences.[19]Temporal and Environmental Metrics
In the Common Vulnerability Scoring System (CVSS) version 2.0, temporal metrics adjust the base score to account for factors that evolve over time, such as the maturity of available exploits and the availability of fixes, providing a more dynamic assessment of a vulnerability's severity as new information emerges.[19] These metrics are optional but recommended for ongoing evaluations, as they reflect changes in exploitability and remediation status that can influence prioritization in security operations.[3] The temporal metric group consists of three components: Exploit Code Maturity (E), Remediation Level (RL), and Report Confidence (RC). Exploit Code Maturity measures the current state of available exploit techniques or code, ranging from Unproven (no known exploits, factor 0.85) to High (reliable exploits in the wild, factor 1.00), with intermediate values for Proof-of-Concept (0.90) and Functional (0.95) exploits; a Not Defined value defaults to 1.00.[19] Remediation Level assesses the availability and quality of fixes, from Official Fix (a complete vendor solution, factor 0.87) to Unavailable (no fix exists, factor 1.00), including Temporary Fix (0.90) and Workaround (0.95); Not Defined also defaults to 1.00.[20] Report Confidence evaluates the credibility of the vulnerability report, from Unconfirmed (doubts about existence, factor 0.90) to Confirmed (fully verified, factor 1.00), with Uncorroborated (0.95) in between; Not Defined defaults to 1.00.[20] The temporal score is calculated using the formula: if the base score is 0, then Temporal Score = 0; otherwise, Temporal Score = round_to_1_decimal(Base Score × E × RL × RC), where rounding is to one decimal place and the result is bounded between 0 and 10, never exceeding the base score or falling below approximately one-third of it.[19] This adjustment typically lowers the score as exploits mature or fixes become available but cannot increase it beyond the base. For example, a base score of 7.5 with a Functional exploit (0.95), Official Fix (0.87), and Confirmed report (1.00) yields a temporal score of round_to_1_decimal(7.5 × 0.95 × 0.87 × 1.00) = 6.2, reflecting reduced urgency due to remediation.[20] Environmental metrics further customize the score to the specific deployment context of an organization, incorporating asset criticality and broader impacts to tailor severity to individual environments.[19] These metrics modify the base (or temporal) assessment by adjusting impact based on asset values and adding factors for systemic exposure and collateral effects. They are particularly useful for enterprises evaluating vulnerabilities across diverse systems, where a high base score might be amplified or diminished based on local configurations.[3] The environmental group includes Collateral Damage Potential (CDP), Target Distribution (TD), and modified Confidentiality (CR), Integrity (IR), and Availability (AR) requirements. Collateral Damage Potential estimates secondary harm beyond the vulnerable component, such as physical damage or loss of life, with values None (0), Low (0.1), Low-Medium (0.3), Medium-High (0.4), High (0.5), and Not Defined (0).[19] Target Distribution gauges the vulnerability's prevalence in the environment, from None (0) to High (1.00, affects a large proportion of systems), with Low (0.25) and Medium (0.75) in between; Not Defined defaults to 1.00.[19] The modified impact metrics override base impacts using asset-specific multipliers: Low priority (0.5), Medium (1.0), High (1.51), or Not Defined (1.0) for each of confidentiality, integrity, and availability, allowing analysts to weight effects on critical assets higher.[3] To compute the environmental score, first derive the Modified Impact subscore as min{10, 10.41 × [1 - (1 - Confidentiality Impact × CR) × (1 - Integrity Impact × IR) × (1 - Availability Impact × AR)]}, using the base impacts adjusted by the requirement multipliers.[19] Then, calculate an Adjusted Base Score by substituting this Modified Impact into the base score formula in place of the original impact. The Adjusted Temporal Score follows by applying temporal factors to this Adjusted Base if temporal metrics are used. Finally, the Environmental Score = round_to_1_decimal([Adjusted Temporal + (10 - Adjusted Temporal) × CDP] × TD), ensuring it ranges from 0 to 10 and does not exceed the temporal score.[20] For instance, if an Adjusted Temporal is 6.0, CDP is Low-Medium (0.3), and TD is High (1.00), the score becomes round_to_1_decimal([6.0 + (10 - 6.0) × 0.3] × 1.00) = 7.2, increasing severity due to widespread targets and collateral risks.[19]| Temporal Metric | Values and Factors |
|---|---|
| Exploit Code Maturity (E) | Unproven (0.85), Proof-of-Concept (0.90), Functional (0.95), High (1.00), Not Defined (1.00) |
| Remediation Level (RL) | Official Fix (0.87), Temporary Fix (0.90), Workaround (0.95), Unavailable (1.00), Not Defined (1.00) |
| Report Confidence (RC) | Unconfirmed (0.90), Uncorroborated (0.95), Confirmed (1.00), Not Defined (1.00) |
| Environmental Metric | Values and Factors |
|---|---|
| Collateral Damage Potential (CDP) | None (0), Low (0.1), Low-Medium (0.3), Medium-High (0.4), High (0.5), Not Defined (0) |
| Target Distribution (TD) | None (0), Low (0.25), Medium (0.75), High (1.00), Not Defined (1.00) |
| Confidentiality/Integrity/Availability Requirements (CR/IR/AR) | Low (0.5), Medium (1.0), High (1.51), Not Defined (1.0) |
Versions 3.0 and 3.1
Key Changes from Version 2.0
Version 3.0 of the Common Vulnerability Scoring System (CVSS) introduced several structural and metric modifications compared to version 2.0 to enhance accuracy and reduce subjectivity in vulnerability assessments. Notably, the Access Complexity metric from version 2.0, which evaluated the ease of exploitation across multiple dimensions, was removed and replaced by two distinct base metrics: Attack Complexity (AC) and User Interaction (UI). Attack Complexity assesses the conditions or actions beyond the attacker's control that must align for successful exploitation, simplified to a binary choice of Low or High to minimize subjective interpretations. User Interaction captures whether a security-aware user must participate in the attack, such as clicking a malicious link, with values of None or Required, thereby addressing social engineering elements more explicitly.[17][21] Additionally, the Authentication metric in version 2.0, which measured the need for successful authentication attempts, was eliminated and supplanted by Privileges Required (PR), a new base metric evaluating the level of privileges an attacker needs before exploitation—None, Low, or High. This shift better reflects modern scenarios involving privilege escalation and varying access controls. A pivotal addition was the Scope (S) metric, which determines whether a vulnerability's impact extends beyond the vulnerable component's security authority (Unchanged or Changed), enabling more precise scoring of cross-system effects like those in virtualized or cloud environments.[17][21] Impact metrics underwent refinement to provide greater granularity, particularly through separate subscores for the vulnerable system and any subsequent systems affected when Scope is Changed. The Confidentiality (C), Integrity (I), and Availability (A) impacts, previously categorized as None, Partial, or Complete in version 2.0, were adjusted to None, Low, or High, with calculations that first assess direct impacts on the vulnerable component and then propagate to subsequent ones if applicable. These changes, along with the inclusion of Physical as an explicit option in the Attack Vector (AV) metric—expanding from Network, Adjacent, and Local in version 2.0—aimed to improve relevance for diverse attack surfaces, including hardware and physical access.[17][21] The overarching rationale for these updates was to better accommodate contemporary vulnerabilities, such as those in web applications and cloud infrastructures, where version 2.0's metrics often led to inconsistent or inaccurate scores due to ambiguities in complexity and authentication. By streamlining options and introducing Scope, CVSS v3.0 reduced scorer subjectivity and enhanced the system's applicability to chained exploits and indirect impacts.[17][21] Version 3.1, released as a minor revision, focused on clarifications without altering metrics or values, emphasizing consistent application. It refined the Attack Vector descriptions, particularly for Adjacent network scenarios involving trusted but logically separated environments like VPNs, and provided more detailed examples for Scope to distinguish security authorities clearly. While no temporal metrics were deprecated, the specification stressed their optional use for simplicity in base scoring, and introduced guidance on generating multiple base scores for vulnerabilities affecting varied platforms. These tweaks further promoted usability and alignment with real-world deployments.[7][6]Metric Specifications
In CVSS versions 3.0 and 3.1, metrics are organized into three main groups—Base, Temporal, and Environmental—that provide a structured assessment of vulnerability severity. The Base metrics reflect the inherent properties of the vulnerability, independent of time or context, while the Temporal metrics account for characteristics of the threat landscape and remediation status. Environmental metrics allow customization based on organizational context. These metrics are represented in a vector string format, such asCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, where Base metrics are mandatory and others are optional.[6]
Base Metrics
The Base group consists of Exploitability and Impact subgroups, with numerical weights assigned to each metric value to contribute to subscore calculations. Version 3.1 includes clarifications on metric application but no changes to values or structure from v3.0.Exploitability Metrics
These metrics assess the ease of exploiting the vulnerability.| Metric | Abbreviation | Values and Weights | Description |
|---|---|---|---|
| Attack Vector | AV | N (Network): 0.85 A (Adjacent): 0.62 L (Local): 0.55 P (Physical): 0.20 | The proximity required for the attacker to access the vulnerable component, ranging from remote network access to direct physical interaction.[6] |
| Attack Complexity | AC | L (Low): 0.77 H (High): 0.44 | The conditions or difficulties an attacker must overcome, such as race conditions or specific configurations, beyond those captured by other metrics.[6] |
| Privileges Required | PR | N (None): 0.85 L (Low): 0.62 (Unchanged Scope) / 0.68 (Changed Scope) H (High): 0.27 (Unchanged) / 0.50 (Changed) | The level of privileges an attacker needs, such as unauthenticated access or administrative rights, to exploit the vulnerability.[6] |
| User Interaction | UI | N (None): 0.85 R (Required): 0.62 | Whether a victim must participate, such as clicking a malicious link.[6] |
Impact Metrics
These evaluate the consequences of successful exploitation on Confidentiality (C), Integrity (I), and Availability (A), modulated by Scope (S).| Metric | Abbreviation | Values and Weights | Description |
|---|---|---|---|
| Scope | S | U (Unchanged): 0 (multiplier) C (Changed): 1.08 (multiplier) | Determines if the vulnerability impacts components beyond its security scope (Unchanged or Changed).[6] |
| Confidentiality | C | N (None): 0 L (Low): 0.22 H (High): 0.56 | The impact on confidentiality, from no loss to total exposure of sensitive data.[6] |
| Integrity | I | N (None): 0 L (Low): 0.22 H (High): 0.56 | The impact on data integrity, ranging from minor modifications to complete attacker control.[6] |
| Availability | A | N (None): 0 L (Low): 0.22 H (High): 0.56 | The impact on system availability, from performance degradation to denial of service.[6] |
Threat Metrics
The Threat group, also known as Temporal metrics, includes three metrics to reflect real-world exploitation status, remediation, and confidence, with weights that adjust the overall score.| Metric | Abbreviation | Values and Weights | Description |
|---|---|---|---|
| Exploit Code Maturity | E | X (Not Defined): 1.0 H (High): 1.0 F (Functional): 0.97 P (Proof-of-Concept): 0.94 U (Unproven): 0.91 | The current state of exploit availability, from widespread attacks to theoretical vulnerabilities without public exploits.[6] |
| Remediation Level | RL | X (Not Defined): 1.0 U (Unavailable): 1.0 W (Workaround): 0.97 T (Temporary Fix): 0.96 O (Official Fix): 0.95 | Availability and ease of mitigation measures.[6] |
| Report Confidence | RC | X (Not Defined): 1.0 C (Confirmed): 1.0 R (Reasonable): 0.96 U (Unknown): 0.92 | The degree of certainty in the vulnerability description.[6] |
Environmental Metrics
These metrics modify the Base metrics to incorporate organizational priorities, using the same value sets as Base where applicable, plus X (Not Defined).- Confidentiality/Integrity/Availability Requirements (CR/IR/AR): Values are H (High): 1.5, M (Medium): 1.0, L (Low): 0.5, X (Not Defined, defaults to M). These adjust the corresponding impact metrics by scaling C/I/A to MC/MI/MA if requirements are specified.[6]
- Modified Base Metrics: Include MAV (Modified Attack Vector), MAC, MPR, MUI, MS (Modified Scope), with values mirroring Base (e.g., MAV:N=0.85) to reflect deployment-specific conditions.[6]
Score Calculations
The Base Score in CVSS v3.1 uses the same formulas as v3.0, with clarifications for consistent application. The Impact Subscore (ISS) is calculated as $1 - [(1 - C) \times (1 - I) \times (1 - A)], where C, I, A are the numerical values (0, 0.22, 0.56). The Impact score is then $6.42 \times \mathrm{ISS} for Unchanged Scope (S:U) or $7.52 \times (\mathrm{ISS} - 0.029) - 3.25 \times (\mathrm{ISS} - 0.02)^{13} for Changed Scope (S:C), capped at 6.0 if ISS ≤ 1 but adjusted for propagation. The Exploitability subscore is $8.22 \times \mathrm{AV} \times \mathrm{AC} \times \mathrm{PR} \times \mathrm{UI}, using Scope-adjusted PR weights. The Base Score is \mathrm{roundup}(\min(\mathrm{Impact} + \mathrm{Exploitability}, 10)) for S:U or \mathrm{roundup}(\min(1.08 \times (\mathrm{Impact} + \mathrm{Exploitability}), 10)) for S:C; 0 if Impact ≤ 0.[6] The Temporal Score modifies the Base Score as \mathrm{roundup}(\mathrm{Base} \times \mathrm{E} \times \mathrm{RL} \times \mathrm{RC}), decreasing as exploits mature or fixes become available.[6] The Environmental Score applies modifications: Modified ISS (MISS) = \min\{1 - [(1 - \mathrm{CR} \times \mathrm{MC}) \times (1 - \mathrm{IR} \times \mathrm{MI}) \times (1 - \mathrm{AR} \times \mathrm{MA})], 0.915\}, then Modified Impact using the same formula as Base but with MISS and MS. Modified Exploitability = $8.22 \times \mathrm{MAV} \times \mathrm{MAC} \times \mathrm{MPR} \times \mathrm{MUI}. Environmental Score = \mathrm{roundup}(\mathrm{roundup}(\min(\mathrm{Modified\ Impact} + \mathrm{Modified\ Exploitability}, 10)) \times \mathrm{E} \times \mathrm{RL} \times \mathrm{RC}) for MS:U or with 1.08 multiplier for MS:C; 0 if Modified Impact ≤ 0.[6] As an illustration, consider a remote information disclosure vulnerability with vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Exploitability = $8.22 \times 0.85 \times 0.77 \times 0.85 \times 0.85 \approx 3.9, ISS = $1 - (1-0.56)(1-0)(1-0) = 0.56, Impact = $6.42 \times 0.56 \approx 3.6 (S:U), Base Score = \mathrm{roundup}(\min(3.6 + 3.9, 10)) = 8.[6]
Version 4.0
Major Updates and Rationale
The development of CVSS version 4.0 was driven by the need to address longstanding criticisms of version 3.1, particularly around metric subjectivity and insufficient granularity for modern threats, following extensive feedback from the CVSS Special Interest Group (SIG) and public consultations spanning 2022 and 2023.[22] The SIG incorporated input from security experts who analyzed millions of vulnerability vectors to refine the framework, culminating in the official release on November 1, 2023.[22] This iterative process aimed to enhance accuracy, reduce ambiguity in assessments, and better support interoperability across vulnerability management tools while adapting to emerging risks such as supply chain compromises.[23] A key structural change was the removal of the Scope metric, which had been criticized for oversimplifying cross-system impacts in version 3.1.[22] Instead, version 4.0 explicitly distinguishes between Vulnerable System Impacts (Confidentiality, Integrity, and Availability, abbreviated as VC, VI, VA) and Subsequent System Impacts (SC, SI, SA), allowing for clearer modeling of vulnerability chaining effects without a binary scope determination.[22] This update provides a more precise representation of how a vulnerability might propagate beyond the initially affected component, addressing feedback that the prior approach led to inconsistent scoring in networked or supply chain scenarios.[23] To mitigate subjectivity in exploitability assessments, version 4.0 introduced the Attack Requirements (AT) Base metric with values of None (N) or Present (P), capturing environmental prerequisites that must be met for an attack to succeed, separate from the inherent Attack Complexity (AC).[22] Similarly, the User Interaction (UI) metric was refined to include Passive (P) and Active (A) values alongside None (N), offering greater nuance in describing required user involvement and reducing interpretive variability reported in version 3.1 analyses.[22] These changes stem from SIG evaluations showing that v3.1's combined complexity metrics often conflated attacker effort with external conditions, leading to subjective scores.[23] Version 4.0 also expanded support for automation and specialized contexts through new Supplemental metrics, including Safety (S) with values of Negligible (N) or Present (P) to quantify potential human safety impacts in Internet of Things (IoT) or operational technology (OT) environments.[22] Additional Supplemental metrics like Automatable (AU: Yes or No), Recovery (R: Automatable, User, Irrecoverable), Value Density (V: Diffuse or Concentrated), Provider Urgency (U: Red, Amber, Green, Clear), and Vulnerability Response Effort (RE: Low, Moderate, High) enable more granular machine-generated assessments and vector extensions for threat-specific details, facilitating automated tooling in large-scale vulnerability management.[22] The rationale emphasizes adapting to evolving threats, such as those in supply chains, by allowing optional extensions via a new CVSS Extensions Framework without altering core Base scores.[23] Regarding backward compatibility, CVSS v4.0 scores are not directly comparable to those from prior versions due to revised metric weights and calculation methods, though qualitative severity ratings (e.g., Low, Medium, High, Critical) were aligned using expert-mapped thresholds from v3.1 to maintain continuity in risk communication.[24] This design choice prioritizes improved precision over numerical equivalence, with the SIG recommending parallel scoring during transition periods to aid adoption.[22]Metric Specifications
In CVSS version 4.0, metrics are organized into four groups—Base, Threat, Environmental, and Supplemental—that provide a structured assessment of vulnerability severity. The Base metrics reflect the inherent properties of the vulnerability, independent of time or context, while the Threat metrics (formerly Temporal) account for characteristics of the threat landscape. Environmental metrics allow customization based on organizational context, and Supplemental metrics offer additional qualitative information without influencing the numerical score. These metrics are represented in a vector string format, such asCVSS: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:U, where Base metrics are mandatory and others are optional.[22]
Base Metrics
The Base group consists of Exploitability and Impact subgroups, with numerical weights assigned to each metric value to contribute to subscore calculations. New in version 4.0, the Attack Requirements (AT) metric addresses conditions beyond the attacker's control that must be met for successful exploitation, and Subsequent System Impacts extend the Impact subgroup to evaluate effects on interconnected systems.Exploitability Metrics
These metrics assess the ease of exploiting the vulnerability.| Metric | Abbreviation | Values and Weights | Description |
|---|---|---|---|
| Attack Vector | AV | N (Network): 0.97 A (Adjacent): 0.68 L (Local): 0.38 P (Physical): 0.20 | The proximity required for the attacker to access the vulnerable component, ranging from remote network access to direct physical interaction.[22] |
| Attack Complexity | AC | L (Low): 0.44 H (High): 0.35 | The conditions or difficulties an attacker must overcome, such as race conditions or specific configurations, beyond those captured by other metrics.[22] |
| Attack Requirements | AT | N (None): 0.85 P (Present): 0.62 | External conditions, such as specific software versions or network topologies, that must exist for exploitation to succeed; absent in prior versions.[22] |
| Privileges Required | PR | N (None): 0.85 L (Low): 0.62 H (High): 0.27 | The level of privileges an attacker needs, such as unauthenticated access or administrative rights, to exploit the vulnerability.[22] |
| User Interaction | UI | N (None): 0.85 P (Passive): 0.62 A (Active): 0.27 | Whether a victim must participate, such as clicking a link (active) or simply receiving content (passive).[22] |
Impact Metrics
These evaluate the consequences of successful exploitation, divided into Vulnerable System Impacts (direct effects on the targeted system) and Subsequent System Impacts (effects on other systems via chaining).| Subgroup | Metric | Abbreviation | Values and Weights | Description |
|---|---|---|---|---|
| Vulnerable System | Confidentiality | VC | N (None): 0 L (Low): 0.22 H (High): 0.56 | The impact on confidentiality of the vulnerable component, from no loss to total exposure of sensitive data.[22] |
| Vulnerable System | Integrity | VI | N (None): 0 L (Low): 0.22 H (High): 0.56 | The impact on data integrity, ranging from minor modifications to complete attacker control.[22] |
| Vulnerable System | Availability | VA | N (None): 0 L (Low): 0.22 H (High): 0.56 | The impact on system availability, from performance degradation to denial of service.[22] |
| Subsequent System | Confidentiality | SC | N (None): 0 L (Low): 0.22 H (High): 0.56 | Propagation of confidentiality impacts to subsequent systems, such as through exploited services.[22] |
| Subsequent System | Integrity | SI | N (None): 0 L (Low): 0.22 H (High): 0.56 | Propagation of integrity impacts beyond the vulnerable system.[22] |
| Subsequent System | Availability | SA | N (None): 0 L (Low): 0.22 H (High): 0.56 | Propagation of availability impacts to connected systems; introduced in version 4.0 to address exploit chaining.[22] |
Threat Metrics
The Threat group, streamlined from prior versions, includes a single metric to reflect real-world exploitation status, with weights that adjust the overall score downward for immature threats.- Exploit Maturity (E): Values include A (Attacked), P (Proof-of-Concept), U (Unreported), and X (Not Defined, defaults to A). This metric captures the current state of exploit availability, from widespread attacks to theoretical vulnerabilities without public exploits. The Threat Score is the Base Score multiplied by the Exploit Maturity multiplier as defined in the specification.[22]
Environmental Metrics
These metrics modify the Base metrics to incorporate organizational priorities and safety considerations, using the same value sets as Base where applicable, plus X (Not Defined) for unspecified cases. They include security requirements that adjust impact based on asset importance.- Confidentiality/Integrity/Availability Requirements (CR/IR/AR): Values are H (High), M (Medium), L (Low), X (Not Defined, defaults to H). These determine the Modified Impact metrics: for example, if a requirement is High and the corresponding Base Impact is Low or None, the Modified Impact is set to High; if Medium, it is set to High if Base is Low, otherwise Base; if Low, it remains Base. Similar rules apply to subsequent impacts (SCR/SIR/SAR).[22]
- Modified Base Metrics: Include abbreviated forms like MAV (Modified Attack Vector) with values mirroring Base (N/A/L/P/X). For impacts, Modified Vulnerable (MVC/MVI/MVA) and Modified Subsequent (MSC/MSI/MSA) use N/L/H/X and weights (0/0.22/0.56).[22]