🚀 CloudSEK becomes first Indian origin cybersecurity company to receive investment from US state fund
Read more
The Common Vulnerability Scoring System (CVSS) is an open framework that rates the severity of a software vulnerability on a scale of 0.0 to 10.0. A higher number signals a more severe flaw, so security teams use CVSS to compare vulnerabilities on a common scale and decide which to address first. The framework is maintained by FIRST, the Forum of Incident Response and Security Teams.
For example, the Apache Log4j vulnerability (CVE-2021-44228), commonly known as Log4Shell, received the maximum CVSS Base Score of 10.0 because it allowed unauthenticated remote code execution and was rapidly exploited in the wild.
CVSS captures how severe a vulnerability is, yet it does not measure the full risk to a specific organization. This guide explains the severity scale, the metric groups, vector strings, the differences between CVSS versions, how CVSS relates to CVE, and how teams move beyond the score to prioritize what attackers actually exploit.
CVSS is a standardized method for describing the characteristics of a vulnerability and producing a numerical score that reflects its severity. The score runs from 0.0, the least severe, to 10.0, the most severe, and a matching qualitative label ranges from None to Critical.Â
Because the framework is open and vendor-neutral, a score produced by one organization means the same thing to another, which lets security teams, researchers, and vendors discuss the same flaw in consistent terms. Scanners, dashboards, and patch-management tools all surface CVSS scores, which is why the framework is a common reference point across security operations.
Every score is backed by a vector string, a compact text representation of the metric values that produced it. FIRST is explicit that a CVSS score measures technical severity rather than risk, and that a score on its own does not replace a full risk assessment. That distinction shapes how mature teams use CVSS: as a starting point for triage, not the final word on what to fix.
CVSS sits at the center of vulnerability management, the ongoing work of finding, ranking, and resolving security flaws. Three uses dominate. Teams use the score to triage, sorting a long list of vulnerabilities so the most severe reach engineers first. They use it to set service-level targets, since many programs tie patch deadlines to severity, such as remediating Critical flaws within days and Medium ones within weeks. And they use it for compliance, because security standards reference CVSS thresholds; the PCI DSS standard has historically required organizations to remediate vulnerabilities at or above a defined CVSS level. A consistent score supports cyber insurance assessments and board reporting on vulnerability exposure, since a shared number lets everyone agree on how serious a flaw is.
CVSS scores map to five qualitative severity ratings. The ranges below apply to CVSS v3.0, v3.1, and v4.0.

CVSS v2 used a coarser scale with only Low, Medium, and High ratings and no None or Critical band, which is why the same raw score can carry a different label depending on the version that produced it. A score of 7.5 is High, an 8.8 sits near the top of High, and anything from 9.0 upward is Critical and warrants urgent attention. Many vulnerability management programs tie remediation deadlines to these bands, treating Critical and High findings as the priority for fast patching.
A CVSS score is assembled from metric groups, each describing a different dimension of a vulnerability. CVSS v4.0 defines four groups.
Most published scores, including those in the National Vulnerability Database, are Base scores. The Threat and Environmental groups let an organization refine that Base score with real-world exploitation data and its own context, while Supplemental metrics add detail without altering the number.
The Base group is built from two sets of metrics. Exploitability metrics describe how hard a vulnerability is to attack: the Attack Vector (whether it is reachable over the network or needs local access), Attack Complexity, Privileges Required, and User Interaction. Impact metrics describe the damage a successful exploit causes, measured as loss of Confidentiality, Integrity, and Availability. CVSS v4.0 added an Attack Requirements metric and split impact into the vulnerable system and any subsequent systems, replacing the single Scope metric used in v3. A higher Exploitability value or a broader impact pushes the Base score up, which is why a remote, unauthenticated flaw with full impact reaches the maximum of 10.0.
The table lists the base metrics and the values each one can take in CVSS v3.1, the version behind most published scores.
A base score is built from two sub-scores that the framework then combines. The Exploitability sub-score reflects how reachable and easy a vulnerability is to attack, drawn from Attack Vector, Attack Complexity, Privileges Required, and User Interaction. The Impact sub-score reflects the damage a successful exploit causes, drawn from the Confidentiality, Integrity, and Availability metrics.Â
In CVSS v3, the Scope metric determines how the two sub-scores merge, and the raw result is capped at 10.0 and rounded up to one decimal place, so a vulnerability scores high only when it is both easy to exploit and damaging. CVSS v4.0 uses a revised scoring method, but the same principle holds: exploitability and impact together drive the number.
A vector string is the machine-readable record of the metric values behind a score. Each metric appears as an abbreviation and a value, separated by slashes, which lets tools store, share, and recalculate a score precisely. Decoding the Base vector for Log4Shell shows how the metrics combine into a 10.0.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Every Exploitability metric sits at its most dangerous value, and every Impact metric is High, which produces the maximum Base score of 10.0. That combination, remote and unauthenticated with total impact, is what makes a vulnerability genuinely critical. Most production vulnerabilities score lower because they need some privilege, local access, or user interaction that raises the bar for an attacker.
A mid-range score shows the contrast. The vector below describes a network-facing information disclosure flaw that needs no privileges or user interaction, yet exposes only limited confidential data and nothing else.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
The exploitability is identical to Log4Shell, remote and unauthenticated, but the impact is a single low confidentiality loss with unchanged scope, so the score lands at 5.3, a Medium. Impact severity, not exploitability alone, is what separates a Medium from a Critical.
CVSS has evolved through several versions since 2005, and each revision has changed how scores are calculated. Knowing the version behind a score matters because the same vulnerability can score differently across versions.
The v4.0 naming convention signals which metric groups a score reflects. CVSS-B is a Base score alone; CVSS-BT adds Threat, CVSS-BE adds Environmental, and CVSS-BTE combines all three. The change encourages teams to look past the Base number and account for exploitation and context.
Searches for a "CVE score" are common, but there is no separate CVE scoring system. When people refer to a CVE score, they mean the CVSS score assigned to that CVE. These two are different things that work together: a CVE is the identifier for a vulnerability, and CVSS is the system that rates how severe it is.
In practice, a scanner reports a CVE such as CVE-2021-44228, and the National Vulnerability Database supplies its CVSS base score of 10.0. The CVE answers what the vulnerability is; the CVSS score answers how severe it is. Calling the number a CVE score is informal shorthand rather than a distinct metric.
The National Vulnerability Database (NVD) publishes CVSS Base Scores for many CVEs, while CVE Numbering Authorities (CNAs) and vendors may also publish their own scores. Depending on timing, security tools may reference either the CNA or NVD score.Â
Anyone can compute a score by entering metric values into a CVSS calculator on the FIRST or NVD website, which returns both the number and its vector string. Threat and Environmental metrics are left to the organization, since exploitation status and asset importance vary by context.
A CVSS base score describes a vulnerability in isolation, and that design carries real limits. The score is static and environment-agnostic: it does not know whether a vulnerable component is exposed to the internet, what data it can reach, or whether a patch is already shielding it. It says nothing about whether the flaw is actually being exploited.
The result is a prioritization problem. Scanners label thousands of findings Critical or High, far more than any team can patch at once, and a base score alone cannot separate the handful under active attack from the many that are unlikely to be touched. FIRST itself advises that CVSS belongs inside a broader risk assessment rather than serving as one. Treating every 9.0 as equally urgent wastes effort on vulnerabilities that pose little real-world threat while genuinely dangerous ones wait.
The gap shows up in the numbers. Only a relatively small proportion of disclosed vulnerabilities are observed being exploited in the wild. A score that arrives late and ignores exploitation cannot, on its own, tell a team where to start.
Two systems add the exploitation context that CVSS omits. The Exploit Prediction Scoring System (EPSS), maintained by FIRST, estimates the probability of a vulnerability being exploited within the next 30 days, expressed from 0 to 1. CISA's Known Exploited Vulnerabilities (KEV) catalog goes further, listing vulnerabilities confirmed to be under attack in the real world. Layering CVSS for severity, EPSS for likelihood, and KEV for confirmation narrows a flood of Critical ratings to the few that demand immediate action.
EPSS reports both a probability and a percentile, so a vulnerability in the 99th percentile is more likely to be exploited than 99 percent of all others. A practical workflow treats any KEV-listed vulnerability as urgent, escalates high-severity flaws that carry a high EPSS probability next, and schedules the rest by severity, which replaces a wall of critical alerts with a ranked queue.
This is where threat intelligence reshapes vulnerability management. CloudSEK Threat Intelligence tracks which CVEs are being weaponized, the exploitation timelines, and the dark web discussion around them, so a security team can prioritize the vulnerabilities attackers are actually using rather than every high CVSS score. Used this way, the score becomes one input among several. It complements, rather than replaces, the exploitation and asset context that turns a severity rating into a defensible remediation decision.
Lower scores indicate less severe vulnerabilities. A score of 0.0 is None, while 9.0 - 10.0 is Critical. Organizations should prioritize remediation based on CVSS together with exploitability and business context.
Yes. Any score from 9.0 to 10.0 is rated Critical, and 10.0 is the maximum, signaling a vulnerability that is easy to exploit and severe in impact. Log4shell (CVE-2021-44228) scored 10.0.
CVE is the unique identifier for a specific vulnerability, maintained by MITRE. CVSS is the scoring system that rates a vulnerability's severity from 0.0 to 10.0, maintained by FIRST. CVE names the flaw; CVSS scores it.
CVSS v4.0 is the current version, released by FIRST in November 2023. It uses four metric groups: Base, Threat, Environmental, and Supplemental, replacing the Temporal group with Threat and removing the Scope metric used in v3.
FIRST, the Forum of Incident Response and Security Teams maintains the CVSS standard. NIST's National Vulnerability Database publishes CVSS Base Scores for many CVEs, while vendors and CVE Numbering Authorities may also publish scores.
No. CVSS measures the technical severity of a vulnerability, not the risk to a specific organization. Risk depends on exploitation likelihood and environment, which is why teams pair CVSS with EPSS, the KEV catalog, and asset context.
