This year marks the 20th anniversary of the Common Vulnerability Scoring System (CVSS), which has become a widely accepted standard for describing software vulnerabilities. Despite decades of use and four generations of the standard — now at version 4.0 — CVSS scoring rules continue to be misused, and the system itself remains the subject of intense debate. So, what do you need to know about CVSS to effectively protect your IT assets?
The CVSS Base Score
According to its developers, CVSS is a tool for describing the characteristics and severity of software vulnerabilities. CVSS is maintained by the Forum of Incident Response and Security Teams (FIRST). It was created to help experts speak a common language about vulnerabilities, and to facilitate automatic processing of data on software flaws. Almost every vulnerability published in major vulnerability registries like CVE, EUVD, or CNNVD includes a severity assessment based on the CVSS scale.
An assessment typically consists of two main parts:
- A numerical rating (CVSS score), which shows how severe the vulnerability is on a scale from 0 to 10. A score of 10 means it’s an extremely dangerous, critical vulnerability.
- A vector, which is a standardized text string that describes the vulnerability’s key characteristics. This includes details like whether it can be exploited remotely over a network or only locally, if elevated privileges are needed, how complex it is to exploit, and what aspects (such as availability, integrity, or confidentiality) of the vulnerable system are affected by exploitation.
Here’s an example using the highly severe and actively exploited vulnerability CVE-2021-44228 (Log4Shell): Base Score 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Let’s break that down: the attack vector is network-based, attack complexity is low, privileges required: none, user interaction isn’t required, the scope indicates the vulnerability impacts other system components, and the impact on confidentiality, integrity, and availability is high. Detailed descriptions of each component are available in the CVSS 3.1 and CVSS 4.0 specifications.
A crucial part of the CVSS system is its scoring methodology — also known as the calculator, and available for both 4.0 and 3.1. By filling in all the vector components, you can automatically get a numerical criticality score.
The original CVSS calculation methodology included three metric groups: Base, Temporal, and Environmental. The first group covers the fundamental and unchanging characteristics of a vulnerability, and forms the basis for calculating the CVSS Base Score. The second group includes characteristics that can change over time — such as the availability of published exploit code. The third group is designed for internal organizational use to account for context-specific factors like the vulnerable application’s scope or the presence of mitigating security controls in the organization’s infrastructure. In CVSS 4.0, the Temporal metrics have evolved into Threat metrics, and a new group of Supplemental metrics has been introduced.
Here’s how the metrics are interconnected. Software vendors or cybersecurity companies typically assess the Base criticality of a vulnerability (referred to as “CVSS-B” in the 4.0 specification). They also often provide an assessment related to the availability and public disclosure of an exploit (CVSS-BT in 4.0, and Temporal in 3.1). This assessment is a modified Base Score; therefore CVSS-B can be higher or lower than CVSS-BT. As for the Environmental score (CVSS-BTE), it’s calculated within a specific organization based on the CVSS-BT, with adjustments made for their unique conditions of using the vulnerable software.
The Evolution of CVSS
The first two versions of CVSS, released in 2005 and 2007, are hardly used today. While you might still find older CVSS scores for modern vulnerabilities, CVSS 3.1 (2019) and CVSS 4.0 (2023) are the most common scoring systems. However, many software vendors and vulnerability registries aren’t in a rush to adopt version 4.0, and they continue to provide CVSS 3.1 scores.
The core idea behind the first CVSS version was to quantify the severity of vulnerabilities via a scoring system — with an initial separation into Base, Temporal, and Environmental metrics. At that stage, the textual descriptions were loosely formalized, and the three groups of metrics were calculated independently.
CVSS 2.0 introduced a standardized vector string and a new logic: a mandatory and unchangeable Base score, a Temporal score calculated from the Base score but accounting for changing factors, and an Environmental score used within specific organizations and conditions derived from either the Base or Temporal score.
Versions 3.0 and 3.1 added the concept of Scope (impact on other system components). They also more precisely defined parameters related to required privileges and user interaction, and they generalized and refined the values of many parameters. Most importantly, these versions attempted to solidify the fact that CVSS measures the severity of a vulnerability — not the risks it creates.
In version 4.0, the creators aimed to make the CVSS metric more useful for business-level assessments of how vulnerabilities impact risk. This is still not a risk metric, though. Attack complexity was split into two distinct components: attack requirements and attack complexity. This highlights the difference between the inherent engineering difficulty of an attack and the external factors or conditions necessary for the attack to succeed. In practical terms, this means a flaw that requires a specific, non-default configuration on the vulnerable product to be exploited will have higher attack requirements and, consequently, a lower overall CVSS score.
The often-misunderstood Scope metric, which simply offered “yes” or “no” options for “impact on other components”, has been replaced. Developers have introduced the clearer concept of “subsequent systems”, which now specifies what aspect of their operation the vulnerability affects. Additionally, a range of supporting indicators has been added — such as the automatability of an exploit and the impact of exploitation on human physical safety. The formulas themselves have also undergone substantial revisions. The influence of various components on the numerical threat score has been re-evaluated based on a vast database of vulnerabilities and real-world exploitation data.
How CVSS 4.0 is changing vulnerability prioritization
For cybersecurity professionals, CVSS 4.0 aims to be more practical and relevant to today’s realities. We’re facing tens of thousands of vulnerabilities — many of which receive a high CVSS score. This often leads to them being automatically flagged for immediate remediation in many organizations. The problem is, these lists are constantly growing, and the average time to fix a vulnerability is nearing seven months.
When vulnerabilities are re-evaluated from CVSS 3.1 to CVSS 4.0, the Base Score for defects with a severity between 4.0 and 9.0 tends to slightly increase. However, for vulnerabilities that were considered critically severe in CVSS 3.1, the score often remains unchanged or even decreases. More importantly, while Temporal metrics had little impact on a vulnerability’s numerical rating before, the influence of Threat and Environmental metrics is now much more significant. Orange Cyberdefense conducted a study to illustrate this. Imagine a company is tracking 8000 vulnerabilities, and their IT and security teams are required to fix all defects with a Base CVSS score above 8 within a specified timeframe. What percentage of these 8000 real-world vulnerabilities would fall into that category — with or without considering exposure of the exploit to the public (Temporal/Threat adjustment)? The study found that CVSS 4.0, in its base version, assigns a score of 8 or higher to a larger percentage of vulnerabilities (33% compared to 18% in version 3.1). However, when adjusted for the availability of exploits, this number drops significantly — leaving fewer truly critical flaws to prioritize (8% versus 10%).
Critical, High, and everything in between
What’s the difference between a “critical” vulnerability and one that’s just plain dangerous? A text-based severity description is part of the specification — but it’s not always required in a vulnerability description:
- Low Severity: 0.1–3.9
- Medium Severity: 4.0–6.9
- High Severity: 7.0–8.9
- Critical Severity: 9.0–10.0
In practice, many software vendors take a creative approach to these text descriptions. They might modify the names or incorporate their own assessments and factors not included in CVSS. A case in point is June’s Microsoft Patch Tuesday — specifically CVE-2025-33064 and CVE-2025-32710. The first is described as “Important” and the second as “Critical”, yet their CVSS 3.1 scores are 8.8 and 8.1, respectively.