Common Vulnerability Scoring System

"CVSS" redirects here. For the school, see Compassvale Secondary School.

The Common Vulnerability Scoring System (CVSS) is a technical standard for assessing the severity of vulnerabilities in computing systems. Scores are calculated based on a formula with several metrics that approximate ease and impact of an exploit. Scores range from 0 to 10, with 10 being the most severe. While many use only the CVSS Base score for determining severity, temporal and environmental scores also exist, to factor in availability of mitigations and how widespread vulnerable systems are within an organization, respectively.

Common Vulnerability Scoring System

Abbreviation	CVSS
Status	Active
First published	February 2005 (2005-02)
Latest version	4.0
Organization	Forum of Incident Response and Security Teams
Domain	Information security
Website	www.first.org/cvss/

The current version of CVSS (CVSSv4.0) was released in November 2023.

CVSS is not intended to be used as a method for patch management prioritization, but is used like that regardless.

History

Research by the National Infrastructure Advisory Council (NIAC) in 2003/2004 led to the launch of CVSS version 1 (CVSSv1) in February 2005, with the goal of being "designed to provide open and universally standard severity ratings of software vulnerabilities". This initial draft had not been subject to peer review or review by other organizations. In April 2005, NIAC selected the Forum of Incident Response and Security Teams (FIRST) to become the custodian of CVSS for future development.

Feedback from vendors using CVSSv1 in production suggested there were "significant issues with the initial draft of CVSS". Work on CVSS version 2 (CVSSv2) began in April 2005 with the final specification being launched in June 2007.

Further feedback resulted in work beginning on CVSS version 3 in 2012, ending with CVSSv3.0 being released in June 2015.

Terminology

The CVSS assessment measures three areas of concern:

1. base metrics for qualities intrinsic to a vulnerability,
2. temporal metrics for characteristics that evolve over the lifetime of vulnerability, and
3. environmental metrics for vulnerabilities that depend on a particular implementation or environment.

A numerical score is generated for each of these metric groups. A vector string (or simply "vector" in CVSSv2) represents the values of all the metrics as a block of text.

Version 2

Complete documentation for CVSSv2 is available from FIRST. A summary is provided below.

Base metrics

Access Vector

The access vector (AV) shows how a vulnerability may be exploited.

Value	Description	Score
Local (L)	The attacker must either have physical access to the vulnerable system (e.g. firewire attacks) or a local account (e.g. a privilege escalation attack).	0.395
Adjacent Network (A)	The attacker must have access to the broadcast or collision domain of the vulnerable system (e.g. ARP spoofing, Bluetooth attacks).	0.646
Network (N)	The vulnerable interface is working at layer 3 or above of the OSI Network stack. These types of vulnerabilities are often described as remotely exploitable (e.g. a remote buffer overflow in a network service)	1.0

Access Complexity

The access complexity (AC) metric describes how easy or difficult it is to exploit the discovered vulnerability.

Value	Description	Score
High (H)	Specialised conditions exist, such as a race condition with a narrow window, or a requirement for social engineering methods that would be readily noticed by knowledgeable people.	0.35
Medium (M)	There are some additional requirements for the attack, such as a limit on the origin of the attack, or a requirement for the vulnerable system to be running with an uncommon, non-default configuration.	0.61
Low (L)	There are no special conditions for exploiting the vulnerability, such as when the system is available to large numbers of users, or the vulnerable configuration is ubiquitous.	0.71

Authentication

The authentication (Au) metric describes the number of times that an attacker must authenticate to a _target to exploit it. It does not include (for example) authentication to a network in order to gain access. For locally exploitable vulnerabilities, this value should only be set to Single or Multiple if further authentication is required after initial access.

Value	Description	Score
Multiple (M)	Exploitation of the vulnerability requires that the attacker authenticate two or more times, even if the same credentials are used each time.	0.45
Single (S)	The attacker must authenticate once in order to exploit the vulnerability.	0.56
None (N)	There is no requirement for the attacker to authenticate.	0.704

Impact metrics

Confidentiality

The confidentiality (C) metric describes the impact on the confidentiality of data processed by the system.

Value	Description	Score
None (N)	There is no impact on the confidentiality of the system.	0.0
Partial (P)	There is considerable disclosure of information, but the scope of the loss is constrained such that not all of the data is available.	0.275
Complete (C)	There is total information disclosure, providing access to any / all data on the system. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact.	0.660

Integrity

The Integrity (I) metric describes the impact on the integrity of the exploited system.

Value	Description	Score
None (N)	There is no impact on the integrity of the system.	0.0
Partial (P)	Modification of some data or system files is possible, but the scope of the modification is limited.	0.275
Complete (C)	There is total loss of integrity; the attacker can modify any files or information on the _target system.	0.660

Availability

The availability (A) metric describes the impact on the availability of the _target system. Attacks that consume network bandwidth, processor cycles, memory, or any other resources affect the availability of a system.

Value	Description	Score
None (N)	There is no impact on the availability of the system.	0.0
Partial (P)	There is reduced performance or loss of some functionality.	0.275
Complete (C)	There is total loss of availability of the attacked resource.	0.660

Calculations

These six metrics are used to calculate the exploitability and impact sub-scores of the vulnerability. These sub-scores are used to calculate the overall base score.

${\textsf {Exploitability}}=20\times {\textsf {AccessVector}}\times {\textsf {AccessComplexity}}\times {\textsf {Authentication}}$

${\textsf {Impact}}=10.41\times (1-(1-{\textsf {ConfImpact}})\times (1-{\textsf {IntegImpact}})\times (1-{\textsf {AvailImpact}}))$

$f({\textsf {Impact}})={\begin{cases}0,&{\text{if }}{\textsf {Impact}}{\text{ = 0}}\\1.176,&{\text{otherwise }}\end{cases}}$

${\textsf {BaseScore}}={\textsf {roundTo1Decimal}}(((0.6\times {\textsf {Impact}})+(0.4\times {\textsf {Exploitability}})-1.5)\times f({\textsf {Impact}}))$

The metrics are concatenated to produce the CVSS Vector for the vulnerability.

Example

A buffer overflow vulnerability affects web server software that allows a remote user to gain partial control of the system, including the ability to cause it to shut down:

Metric	Value	Description
Attack Vector	Network	The vulnerability may be accessed from any network that can access the _target system — typically the whole of the internet.
Attack Complexity	Low	There are no special requirements for access.
Authentication	None	There is no requirement for authentication in order to exploit the vulnerability.
Confidentiality	Partial	The attacker can read some files and data on the system.
Integrity	Partial	The attacker can alter some files and data on the system.
Availability	Complete	The attacker can cause the system and web service to become unavailable / unresponsive by shutting the system down.

This would give an exploitability sub-score of 10, and an impact sub-score of 8.5, giving an overall base score of 9.0. The vector for the base score in this case would be AV:N/AC:L/Au:N/C:P/I:P/A:C. The score and vector are normally presented together to allow the recipient to fully understand the nature of the vulnerability and to calculate their own environmental score if necessary.

Temporal metrics

The value of temporal metrics change over the lifetime of the vulnerability, as exploits are developed, disclosed and automated and as mitigations and fixes are made available.

Exploitability

The exploitability (E) metric describes the current state of exploitation techniques or automated exploitation code.

Value	Description	Score
Unproven (U)	No exploit code is available, or the exploit is theoretical.	0.85
Proof-of-concept (P)	Proof-of-concept exploit code or demonstration attacks are available, but not practical for widespread use. Not functional against all instances of the vulnerability.	0.9
Functional (F)	Functional exploit code is available, and works in most situations where the vulnerability is present.	0.95
High (H)	The vulnerability can be exploited by automated code, including mobile code (such as a worm or virus).	1.0
Not Defined (ND)	This is a signal to ignore this score.	1.0

Remediation Level

The remediation level (RL) of a vulnerability allows the temporal score of a vulnerability to decrease as mitigations and official fixes are made available.

Value	Description	Score
Official Fix (O)	A complete vendor solution is available — either a patch or an upgrade.	0.87
Temporary Fix (T)	There is an official but temporary fix / mitigation available from the vendor.	0.90
Workaround (W)	There is an unofficial, non-vendor solution or mitigation available — perhaps developed or suggested by users of the affected product or another third party.	0.95
Unavailable (U)	There is no solution available, or it is impossible to apply a suggested solution. This is the usual initial state of the remediation level when a vulnerability is identified.	1.0
Not Defined (ND)	This is a signal to ignore this score.	1.0

Report Confidence

The report confidence (RC) of a vulnerability measures the level of confidence in the existence of the vulnerability and also the credibility of the technical details of the vulnerability.

Value	Description	Score
Unconfirmed (UC)	A single unconfirmed source, or multiple conflicting sources. Rumored vulnerability.	0.9
Uncorroborated (UR)	Multiple sources that broadly agree — there may be a level of remaining uncertainty about the vulnerability	0.95
Confirmed (C)	Acknowledged and confirmed by the vendor or manufacturer of the affected product.	1.0
Not Defined (ND)	This is a signal to ignore this score.	1.0

Calculations

These three metrics are used in conjunction with the base score that has already been calculated to produce the temporal score for the vulnerability with its associated vector.

The formula used to calculate the temporal score is:

${\textsf {TemporalScore}}={\textsf {roundTo1Decimal}}({\textsf {BaseScore}}\times {\textsf {Exploitability}}\times {\textsf {RemediationLevel}}\times {\textsf {ReportConfidence}})$

Example

To continue with the example above, if the vendor was first informed of the vulnerability by a posting of proof-of-concept code to a mailing list, the initial temporal score would be calculated using the values shown below:

Metric	Value	Description
Exploitability	Proof-of-concept	Proof-of concept, non-automated code is provided to show basic exploit functionality.
Remediation Level	Unavailable	The vendor has not yet had the opportunity to provide a mitigation or fix.
Report Confidence	Unconfirmed	There has been a single report of the vulnerability.

This would give a temporal score of 7.3, with a temporal vector of E:P/RL:U/RC:UC (or a full vector of AV:N/AC:L/Au:N/C:P/I:P/A:C/E:P/RL:U/RC:UC).

If the vendor then confirms the vulnerability, then the score rises to 8.1, with a temporal vector of E:P/RL:U/RC:C

A temporary fix from the vendor would reduce the score back to 7.3 (E:P/RL:T/RC:C), while an official fix would reduce it further to 7.0 (E:P/RL:O/RC:C). As it is not possible to be confident that every affected system has been fixed or patched, the temporal score cannot reduce below a certain level based on the vendor's actions, and may increase if an automated exploit for the vulnerability is developed.

Environmental metrics

The environmental metrics use the base and current temporal score to assess the severity of a vulnerability in the context of the way that the vulnerable product or software is deployed. This measure is calculated subjectively, typically by affected parties.

Collateral Damage Potential

The collateral damage potential (CDP) metric measures the potential loss or impact on either physical assets such as equipment (and lives), or the financial impact upon the affected organisation if the vulnerability is exploited.

Value	Description	Score
None (N)	No potential for loss of property, revenue or productivity	0
Low (L)	Slight damage to assets, or minor loss of revenue or productivity	0.1
Low-Medium (LM)	Moderate damage or loss	0.3
Medium-High (MH)	Significant damage or loss	0.4
High (H)	Catastrophic damage or loss	0.5
Not Defined (ND)	This is a signal to ignore this score.	0

_target Distribution

The _target distribution (TD) metric measures the proportion of vulnerable systems in the environment.

Value	Description	Score
None (N)	No _target systems exist, or they only exist in laboratory settings	0
Low (L)	1–25% of systems at risk	0.25
Medium (M)	26–75% of systems at risk	0.75
High (H)	76–100% of systems at risk	1.0
Not Defined (ND)	This is a signal to ignore this score.	1.0

Impact Subscore Modifier

Three further metrics assess the specific security requirements for confidentiality (CR), integrity (IR) and availability (AR), allowing the environmental score to be fine-tuned according to the users' environment.

Value	Description	Score
Low (L)	Loss of (confidentiality / integrity / availability) is likely to have only a limited effect on the organisation.	0.5
Medium (M)	Loss of (confidentiality / integrity / availability) is likely to have a serious effect on the organisation.	1.0
High (H)	Loss of (confidentiality / integrity / availability) is likely to have a catastrophic effect on the organisation.	1.51
Not Defined (ND)	This is a signal to ignore this score.	1.0

Calculations

The five environmental metrics are used in conjunction with the previously assessed base and temporal metrics to calculate the environmental score and to produce the associated environmental vector.

${\textsf {AdjustedImpact}}=\min(10,10.41\times (1-(1-{\textsf {ConfImpact}}\times {\textsf {ConfReq}})\times (1-{\textsf {IntegImpact}}\times {\textsf {IntegReq}})\times (1-{\textsf {AvailImpact}}\times {\textsf {AvailReq}})))$

${\textsf {AdjustedTemporal}}={\textsf {TemporalScore}}{\text{ recomputed with the }}{\textsf {BaseScore}}{\text{s }}{\textsf {Impact}}{\text{ sub-equation replaced with the }}{\textsf {AdjustedImpact}}{\text{ equation}}$

${\textsf {EnvironmentalScore}}={\textsf {roundTo1Decimal}}(({\textsf {AdjustedTemporal}}+(10-{\textsf {AdjustedTemporal}})\times {\textsf {CollateralDamagePotential}})\times {\textsf {_targetDistribution}})$

Example

If the aforementioned vulnerable web server were used by a bank to provide online banking services, and a temporary fix was available from the vendor, then the environmental score could be assessed as:

Metric	Value	Description
Collateral Damage Potential	Medium-High	This value would depend on what information the attacker is able to access if a vulnerable system is exploited. In this case I am assuming that some personal banking information is available, therefore there is a significant reputational impact on the bank.
_target Distribution	High	All of the bank's web servers run the vulnerable software.
Confidentiality Requirement	High	Customers expect their banking information to be confidential.
Integrity Requirement	High	Financial and personal information should not be changeable without authorization.
Availability Requirement	Low	Unavailability of online banking services is likely to be an inconvenience for customers, but not catastrophic.

This would give an environmental score of 8.2, and an environmental vector of CDP:MH/TD:H/CR:H/IR:H/AR:L. This score is within the range 7.0-10.0, and therefore constitutes a critical vulnerability in the context of the affected bank's business.

Criticism of Version 2

Several vendors and organizations expressed dissatisfaction with CVSSv2.

Risk Based Security, which manages the Open Source Vulnerability Database, and the Open Security Foundation jointly published a public letter to FIRST regarding the shortcomings and failures of CVSSv2. The authors cited a lack of granularity in several metrics, which results in CVSS vectors and scores that do not properly distinguish vulnerabilities of different type and risk profiles. The CVSS scoring system was also noted as requiring too much knowledge of the exact impact of the vulnerability.

Oracle introduced the new metric value of "Partial+" for Confidentiality, Integrity, and Availability, to fill perceived gaps in the description between Partial and Complete in the official CVSS specifications.

Version 3

To address some of these criticisms, development of CVSS version 3 was started in 2012. The final specification was named CVSSv3.0 and released in June 2015. In addition to a Specification Document, a User Guide and Examples document were also released.

Several metrics were changed, added, and removed. The numerical formulas were updated to incorporate the new metrics while retaining the existing scoring range of 0-10. Textual severity ratings of None (0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0) were defined, similar to the categories NVD defined for CVSSv2 that were not part of that standard.

Changes from Version 2

Base metrics

In the Base vector, the new metrics User Interaction (UI) and Privileges Required (PR) were added to help distinguish vulnerabilities that required user interaction or user or administrator privileges to be exploited. Previously, these concepts were part of the Access Vector metric of CVSSv2. UI can take the values None or Required; attacks that do not require logging in as a user are considered more severe. PR can take the values None, Low, or High; similarly, attacks requiring fewer privileges are more severe.

The Base vector also saw the introduction of the new Scope (S) metric, which was designed to make clear which vulnerabilities may be exploited and then used to attack other parts of a system or network. These new metrics allow the Base vector to more clearly express the type of vulnerability being evaluated.

The Confidentiality, Integrity, and Availability (C, I, A) metrics were updated to have scores consisting of None, Low, or High, rather than the None, Partial, and Complete of CVSSv2. This allows more flexibility in determining the impact of a vulnerability on CIA metrics.

Access Complexity was renamed Attack Complexity (AC) to make clear that access privileges were moved to a separate metric. This metric now describes how repeatable exploit of this vulnerability may be; AC is High if the attacker requires perfect timing or other circumstances (other than user interaction, which is also a separate metric) which may not be easily duplicated on future attempts.

Attack Vector (AV) saw the inclusion of a new metric value of Physical (P), to describe vulnerabilities that require physical access to the device or system to perform.

Temporal metrics

The Temporal metrics were essentially unchanged from CVSSv2.

Environmental metrics

The Environmental metrics of CVSSv2 were completely removed and replaced with essentially a second Base score, known as the Modified vector. The Modified Base is intended to reflect differences within an organization or company compared to the world as a whole. New metrics to capture the importance of Confidentiality, Integrity, and Availability to a specific environment were added.

Criticism of Version 3

In a blog post in September 2015, the CERT Coordination Center discussed limitations of CVSSv2 and CVSSv3.0 for use in scoring vulnerabilities in emerging technology systems such as the Internet of Things.

Version 3.1

A minor update to CVSS was released on June 17, 2019. The goal of CVSSv3.1 was to clarify and improve upon the existing CVSSv3.0 standard without introducing new metrics or metric values, allowing for frictionless adoption of the new standard by both scoring providers and scoring consumers alike. Usability was a prime consideration when making improvements to the CVSS standard. Several changes being made in CVSSv3.1 are to improve the clarity of concepts introduced in CVSSv3.0, and thereby improve the overall ease of use of the standard.

FIRST has used input from industry subject-matter experts to continue to enhance and refine CVSS to be more and more applicable to the vulnerabilities, products, and platforms being developed over the past 15 years and beyond. The primary goal of CVSS is to provide a deterministic and repeatable way to score the severity of a vulnerability across many different constituencies, allowing consumers of CVSS to use this score as input to a larger decision matrix of risk, remediation, and mitigation specific to their particular environment and risk tolerance.

Updates to the CVSSv3.1 specification include clarification of the definitions and explanation of existing base metrics such as Attack Vector, Privileges Required, Scope, and Security Requirements. A new standard method of extending CVSS, called the CVSS Extensions Framework, was also defined, allowing a scoring provider to include additional metrics and metric groups while retaining the official Base, Temporal, and Environmental Metrics. The additional metrics allow industry sectors such as privacy, safety, automotive, healthcare, etc., to score factors that are outside the core CVSS standard. Finally, the CVSS Glossary of Terms has been expanded and refined to cover all terms used throughout the CVSSv3.1 documentation.

Version 4.0

Version 4.0 was officially released in November 2023, and is available at FIRST. Among several clarifications, the most notable changes are the new base metric Attack Requirements which complement the metric Attack Complexity with an assessment what conditions at the _target side are needed to exploit a vulnerability. Further, the Impact metrics are split into impact on the vulnerable system itself and impact on subsequent systems (this replaces the Scope metric from prior versions).

The base metrics are now as follows.

• Attack Vector (AV): Over which (physical) way can you exploit a vulnerability? [N] network, [A] adjacent (i.e., limited to direct connections), [I] interaction (e.g. via SSH or Keyboard), or [P] physical (e.g. manipulate or observe hardware).
• Attack Complexity (AC): Are there any further counter measures the attacker has to circumvent, and how hard is it to do so? [L] low, or [H] high (e.g. data execution prevention).
• Attack Requirements (AT): Are there any conditions necessary for an attack which the attacker cannot influence? [N] none, or [P] present (e.g. a race condition must be won, or the system is in a specific state).
• Privileges Required (PR): Is it required to have any privileges on the _target system? [N] none (unauthenticated), [L] low (normal user), or [H] high (administrative access).
• User Interaction (UI): Does the (legitimate) user of the system need to do anything to make the attack possible? [N] none, [P] passive (e.g. accidentally visiting a malicious website), or [A] active (e.g. executing a malicious office macro).
• Vulnerable System Confidentiality Impact (VC): [N] none, [L] low, or [H] high.
• Vulnerable System Integrity Impact (VI): [N] none, [L] low, or [H] high.
• Vulnerable System Availability Impact (VA): [N] none, [L] low, or [H] high.
• Subsequent System Confidentiality Impact (SC): [N] none, [L] low, or [H] high.
• Subsequent System Integrity Impact (SI): [N] none, [L] low, or [H] high.
• Subsequent System Availability Impact (SA): [N] none, [L] low, or [H] high.

Additionally to these base metrics, there are optional metrics regarding public availability of an exploit, environment specific thread modelling, system recovery, and others.

Example

Assume there is an SQL-Injection in an online web shop. The database user of the online shop software only has read access to the database. Further the injection is in a view of the shop which is only visible to registered customers. The CVSS 4.0 base vector is as follows.

• AV:N as the vulnerability can be triggered over the web
• AC:L as SQL-Injections can be exploited reliably via scripts (assuming the online shop has no counter measures).
• AT:N as the attack doesn't depend on specific system conditions
• PR:L as attackers need to be authenticated as regular user, but no administrative rights are needed
• UI:N as no other users are involved
• VC:H as attackers can read all tables in the database
• VI:N as attackers have no write access
• VA:L as attackers might execute long queries on the database which temporarily render the database slower or unresponsive
• SC:N (we have no further information on subsequent systems)
• SI:N (we have no further information on subsequent systems)
• SA:L we can expect other systems involved in order management and logistics to be affected by an unresponsive database

This results in the vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:L

Adoption

Versions of CVSS have been adopted as the primary method for quantifying the severity of vulnerabilities by a wide range of organizations and companies, including:

• The National Vulnerability Database (NVD)
• The Open Source Vulnerability Database (OSVDB)
• CERT Coordination Center, which in particular makes use of CVSSv2 Base, Temporal and Environmental metrics

See also

• Common Weakness Enumeration (CWE)
• Common Vulnerabilities and Exposures (CVE)
• Common Attack Pattern Enumeration and Classification (CAPEC)

External links

• The Forum of Incident Response and Security Teams (FIRST) CVSS site
• National Vulnerability Database (NVD) CVSS site
• Common Vulnerability Scoring System v2 Calculator