GeezerVison

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 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.^[1]

The current version of CVSS (CVSS v4.0) was released in November 2023.^[2]

CVSS is not intended as a method for patch prioritization, but is often used as one regardless.^[3] 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.^[4]

Research by the National Infrastructure Advisory Council (NIAC) in 2003/2004 led to the launch of CVSS version 1 (CVSS v1) in February 2005,^[5] 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.^[6][7]

Feedback from vendors using CVSS v1 found "significant issues with the initial draft". Work on CVSS v2 began in April 2005 with the final specification being launched in June 2007.^[8]

Further feedback lead to work on CVSS version 3^[9] in 2012, with CVSS v3.0 being released in June 2015.^[10][5]

The CVSS assessment measures:

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 score is generated for each group and a vector string represents the values of all the metrics as a block of text.

Complete documentation for CVSS v2 is available from FIRST.^[11] A summary is provided below.

To address some of these criticisms, development of CVSS version 3 started in 2012. CVSS v3.0 was released in June 2015 with a Specification Document, User Guide and Examples document.^[14]

Several metrics were changed, added, and removed. The numerical formulas were updated to incorporate 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)^[15] were defined, similar to the categories NVD defined for CVSS v2 that were not part of that standard.^[16]

A minor update to CVSS was released on June 17, 2019. The goal of CVSS v3.1 was to clarify and improve upon the existing CVSS v3.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 CVSS v3.1 are to improve the clarity of concepts introduced in CVSS v3.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 CVSS v3.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 CVSS v3.1 documentation.

Version 4.0 was officially released in November 2023,^[2] and is available at FIRST.org.^[18] Among several clarifications, the most notable changes are the new base metric Attack Requirements which complement the metric Attack Complexity with an assessment of what conditions at the target site 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.

In January 2026, the standards body released a new Consumer Implementation Guide^[19] that details the use of Threat and Environmental metrics to produce scores that more accurately reflect the deployment environment and threat activity. The guide also introduces a maturity model to explain how these additional metric groups improve scores for improved real-world triage and resource allocation.

For illustrative purposes, assume there is an SQL injection vulnerability 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 a 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

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)^[20]
• The Open Source Vulnerability Database (OSVDB)^[21]
• CERT Coordination Center,^[22] which in particular makes use of CVSS v2 Base, Temporal and Environmental metrics

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

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