Contact Us

CVSS (Common Vulnerability Scoring System)

Field: Security · Also called: Common Vulnerability Scoring System, CVSS score, CVSS base score, CVSS v4.0, CVSS v3.1, vulnerability severity score

The Common Vulnerability Scoring System (CVSS) is an open framework, maintained by FIRST, for communicating the characteristics and severity of software, hardware, and firmware vulnerabilities. It produces a score from 0.0 to 10.0 that can be mapped to a qualitative rating of None, Low, Medium, High, or Critical.

The severity scale

CVSS versions 3.1 and 4.0 use the same qualitative rating scale:

Rating CVSS score
None 0.0
Low 0.1 – 3.9
Medium 4.0 – 6.9
High 7.0 – 8.9
Critical 9.0 – 10.0

The range is wide. The highest scores go to vulnerabilities that an unauthenticated attacker can exploit across a network with no help from any other user, and that cause a total loss of confidentiality and integrity, the profile of an unauthenticated remote code execution. The low end is a vulnerability that needs local or physical access, or existing privileges, and that only reduces performance or interrupts service, a minor denial of service. Both appear in the same advisory feeds, scanner reports, and compliance checklists under a CVE ID, and the scale exists to tell them apart.

What drives the score

The Base metrics describe how a vulnerability is exploited and what it affects. Three of the exploitability metrics are:

  • Attack Vector. The score is higher the more remote the attacker can be, with exploitation across a network scoring highest.
  • Privileges Required. The score is greatest when the attacker needs no privileges, that is, no account, before the attack.
  • User Interaction. The score is greatest when no other user has to take part, such as by opening a file or clicking a link.

The impact metrics then rate the effect on the confidentiality, integrity, and availability of the vulnerable system and of subsequent systems affected downstream, the first three properties of CIANA.

Severity is not risk

NIST’s National Vulnerability Database (NVD) puts it plainly: “CVSS is not a measure of risk.” CVSS v4.0 has four metric groups. The Base group represents the intrinsic qualities of a vulnerability that are constant over time and across environments, and it assumes the reasonable worst-case impact across the environments where the software is deployed. The Threat group reflects characteristics that change over time, such as whether proof-of-concept exploit code is public or attacks have been reported. The Environmental group reflects what is unique to a particular organization, such as mitigating controls and how important the affected system is. The Supplemental group adds context without changing the score.

Base scores usually come from the product’s vendor or a vulnerability analyst, and the specification notes that assessment providers such as the NVD typically publish only Base scores. The specification says that applying the Threat and Environmental metrics “is the responsibility of the CVSS consumer,” and asks that every score be labeled with the metrics used to produce it: CVSS-B for Base only, CVSS-BT, CVSS-BE, or CVSS-BTE. It also describes CVSS as one input to an organization’s vulnerability management process, alongside factors that are not part of CVSS, such as regulatory requirements, the number of customers affected, and monetary losses from a breach.

In threat modeling terms, a published Base score is a worst-case starting point, not an answer. Under CVSS v4.0, a score with no Threat metrics is calculated as if the vulnerability were already being attacked, and one with no Environmental metrics as if the affected system were critical to the organization. Refining those metrics with current threat intelligence and knowledge of the organization’s own systems lets a severity score serve as one input to Likelihood Ă— Impact = Risk.

U.S. federal patch deadlines follow the same logic. CISA’s Binding Operational Directive 26-04, which superseded BOD 22-01 and BOD 19-02, sets remediation timelines for federal agencies from four questions: whether the vulnerable asset is publicly exposed, whether the vulnerability is in CISA’s Known Exploited Vulnerabilities (KEV) catalog, whether an adversary can automate its exploitation, and whether exploitation gives partial or total control of the asset. That last question is a coarse, severity-like judgment, but the numeric CVSS score is not one of the inputs. The shortest timeline is three days. It applies, for example, to a publicly exposed vulnerability that is in the KEV catalog and can be exploited automatically, and also to some that are not in the catalog. A forensic triage, to check whether the system was already compromised, is added when a KEV vulnerability gives total control of a system that is publicly exposed or whose exploitation can be automated. Other KEV vulnerabilities get 14 days. The clock starts when CISA adds the vulnerability to the catalog or when the agency finds it on an asset, whichever comes first. For example, CISA added CVE-2026-21962, a CVSS v3.1 10.0 flaw in Oracle HTTP Server and the Oracle WebLogic Server Proxy Plug-in, to the KEV catalog on August 24, 2026, with a due date of August 27, 2026, seven months after Oracle released the fix in its January 2026 Critical Patch Update.

Reading a score

A full CVSS assessment is written as a vector string, a compressed text form of every metric value behind the score. This example from the v4.0 specification describes a network-exploitable vulnerability that requires high privileges and has low confidentiality and integrity impact:

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

FIRST requires anyone who publishes CVSS data to provide both the score and the vector string, so others can see how the score was derived, not just the number.

A score should also be read with its version. FIRST first published the CVSS v4.0 specification on November 1, 2023. Version 3.1 uses the same severity scale but has Temporal metrics in place of v4.0’s Threat metrics, and the NVD supports CVSS v2.0, v3.x, and v4.0. CVSS v2.0 itself defined no qualitative ratings; the NVD labeled v2.0 scores from 7.0 to 10.0 as High, with no Critical rating. The NVD stopped producing CVSS v2.0 assessments for new CVE records on July 13, 2022.

A maximum score doesn’t always mean the details are known. When the NVD assesses a vulnerability whose vendor withheld the details needed to score it, the NVD assigns metric values on a worst-case basis, so a vulnerability published with no details at all is assessed as 10.0. Since April 15, 2026, however, the NVD prioritizes its own analysis for a subset of CVEs and no longer routinely adds a separate score when the CNA has supplied one, so for most CVEs the score in the CVE Record comes from the CNA.

Sources

See also

Go deeper

Articles