CVSS (Common Vulnerability Scoring System) is an open standard for rating the technical severity of software vulnerabilities on a scale from 0.0 to 10.0. In cybersecurity vulnerability management, it gives vendors, researchers and defenders a common language: each vulnerability is described by a set of standardized metrics, and a fixed formula turns them into a numeric score and a severity rating.
CVSS is maintained by FIRST, the Forum of Incident Response and Security Teams. Version 3.1 remains the most widely published, and version 4.0, released in 2023, is gradually being adopted. A CVSS score accompanies most CVE records, but the two are distinct: a CVE identifies a vulnerability, while CVSS describes how severe it is.
How a CVSS score is calculated
A CVSS assessment starts with the base metrics, which describe properties of the vulnerability that do not change over time or between environments. They fall into two groups: exploitability metrics, describing how the vulnerability can be reached and triggered, and impact metrics, describing what an attacker gains.
| Metric | Possible values | What it captures |
|---|---|---|
| Attack vector (AV) | Network, Adjacent, Local, Physical | How remote the attacker can be |
| Attack complexity (AC) | Low, High | Conditions outside attacker control |
| Privileges required (PR) | None, Low, High | Access needed before exploiting |
| User interaction (UI) | None, Required | Whether a victim must act |
| Scope (S) | Unchanged, Changed | Whether impact crosses a security boundary |
| Confidentiality, integrity, availability | High, Low, None | Impact on each property of the CIA triad |
The result is published as a vector string that records every choice, for example CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which yields a base score of 9.8. The vector matters more than the number, because it shows why the score is high and lets others verify or adjust it.
Severity ratings and metric groups
Scores map onto qualitative severity ratings that are used in advisories, patch policies and service level agreements.
| Rating | Score range |
|---|---|
| None | 0.0 |
| Low | 0.1-3.9 |
| Medium | 4.0-6.9 |
| High | 7.0-8.9 |
| Critical | 9.0-10.0 |
Beyond the base metrics, CVSS defines optional groups. In version 3.1, temporal metrics reflect exploit code maturity, availability of a fix and confidence in the report, and they can only lower the score. Environmental metrics let an organization adjust the score for its own systems, for example by marking confidentiality as especially important or an attack vector as unreachable.
What changed in CVSS 4.0
CVSS 4.0 addresses long-standing criticism that 3.x scores clustered at the high end and ignored real-world exploitation. It renames and restructures the metric groups and adds finer distinctions.
| Aspect | CVSS 3.1 | CVSS 4.0 |
|---|---|---|
| Metric groups | Base, temporal, environmental | Base, threat, environmental, supplemental |
| Attack prerequisites | Folded into attack complexity | Separate attack requirements (AT) metric |
| User interaction | None or required | None, passive or active |
| Scope | Single scope metric | Separate impacts on vulnerable and subsequent systems |
| Exploitation status | Exploit code maturity, rarely used | Exploit maturity in the threat group |
| Score naming | One score label | CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE |
The new naming convention makes clear which groups contributed to a number. A published CVSS-B score reflects base metrics only, while a CVSS-BTE score includes threat intelligence and the specific environment, and should therefore be the basis for internal prioritization.
CVSS among related vulnerability concepts
CVSS is frequently mixed up with identifiers and classifications that serve different purposes. Using each for its intended role avoids confusion in reports and tools.
| Concept | Answers the question | Example |
|---|---|---|
| CVSS | How severe is this vulnerability technically | 9.8 Critical |
| CVE | Which specific vulnerability is this | A unique CVE-year-number identifier |
| CWE | What kind of weakness caused it | Out-of-bounds write, SQL injection |
| EPSS | How likely is exploitation soon | A probability between 0 and 1 |
| KEV catalog | Is it known to be exploited now | Listed or not listed |
Consequences such as RCE or privilege escalation appear in CVSS through the impact metrics and scope, while a zero-day simply means no fix exists yet. CVSS itself does not say whether a vulnerability is being exploited; that information comes from threat metrics or external sources.
Using CVSS correctly and its limitations
The most important rule is that CVSS measures severity, not risk. Risk also depends on how exposed the affected system is, how valuable it is and whether attackers are actively using the flaw. Patching strictly in order of base score can leave a moderate but actively exploited vulnerability unpatched while effort goes to unreachable critical ones.
- Combine CVSS with exploitation data and asset criticality when setting patch priorities.
- Apply environmental metrics for internet-facing systems versus isolated internal ones.
- Read the vector string, not only the number, when vendors and databases disagree on a score.
- Expect scoring differences between sources, because analysts may judge attack complexity or scope differently.
- Do not compare scores across versions directly; a 3.1 score and a 4.0 score of the same flaw may differ.
The idea in brief
CVSS is a severity scale for security flaws, a little like a hurricane scale for storms. Experts answer a fixed list of questions about each flaw, such as whether it can be attacked over the internet and what an attacker could gain, and the answers produce a score from 0 to 10.
A higher number means a more dangerous flaw in general. However, the score describes the flaw itself, not a particular company, so each organization still has to judge how much it matters for its own systems.
A practical scenario
A mid-sized retailer’s security team receives a monthly vulnerability scan listing about 1,200 findings, 90 of them rated Critical by base score. Patching everything at once is impossible within the two-week maintenance window, so the team builds a prioritization rule that starts from the CVSS vector.
Findings with AV:N on internet-facing servers, or listed as known exploited, go to the top. A critical flaw with AV:L on an isolated reporting server is adjusted through environmental metrics and scheduled later, while a medium-rated but actively exploited VPN vulnerability is patched the same day. The first window closes the exposures most likely to be attacked, rather than simply the highest numbers.