The Common Vulnerability Scoring System (CVSS) is a framework for rating the severity of computer system vulnerabilities. Scores are calculated from metrics that approximate the ease and impact of exploits. Scores range from 0 (minor) to 10 (severe). While many use only the CVSS Base score for determining severity, temporal and environmental scores also exist, to account for the availability of mitigations and the number of vulnerable systems within an organization, respectively.
The current version of CVSS (CVSSv4.0) was released in November 2023.
CVSS is not intended as a method for patch prioritization, but is often used as one regardless. A more effective approach is to integrate CVSS with predictive models like the Exploit Prediction Scoring System (EPSS), to prioritize remediation based on the likelihood of real-world exploitation.
History Research by the National Infrastructure Advisory Council (NIAC) in 2003/2004 led to the launch of CVSS version 1 (CVSSv1) in February 2005, being "designed to provide open and universally standard severity ratings of software vulnerabilities". This initial draft was not subject to outside review. In April 2005, NIAC selected the Forum of Incident Response and Security Teams to further develop CVSS.
Feedback from vendors using CVSSv1 found "significant issues with the initial draft". Work on CVSSv2 began in April 2005 with the final specification being launched in June 2007.
Further feedback lead to work on CVSS version 3 in 2012, with CVSSv3.0 being released in June 2015.
Terminology The CVSS assessment measures: base metrics for qualities intrinsic to a vulnerability, temporal metrics for characteristics that evolve over the lifetime of vulnerability, and environmental metrics for vulnerabilities that depend on a particular implementation or environment.
A score is generated for each group and a vector string 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) Specialized 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.
(Exploitability) = 20(AccessVector)(AccessComplexity)(Authentication)
(Impact) = 10.41(1 − (1 − (ConfImpact))(1 − (IntegImpact))(1 − (AvailImpact)))
|𝑓(Impact) = ||
(BaseScore) = (roundTo1Decimal)( ((0.6(Impact)) + (0.4(Exploitability)) − 1.5)𝑓(Impact))
The metrics are concatenated to produce the CVSS Vector for the vulnerability.
Example A buffer overflow vulnerability affects web server software, allowing remote users to gain partial control of the system, including the ability to cause shut-downs:
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 score of 10, and an impact score of 8.5, giving a base score of 9.0. The vector for this example's base score is AV:N/AC:L/Au:N/C:P/I:P/A:C. The score and vector are normally presented together to allow recipients to fully understand the vulnerability and to calculate their own 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:
Example To continue with the example above, if the vendor were 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.