What Is CVSS? The Vulnerability Scoring System

A CVSS score (Common Vulnerability Scoring System) is a number from 0.0 to 10.0 that captures how severe a software vulnerability is — how easy it is to exploit and how much damage a successful exploit could do. It’s the industry-standard way vendors, researchers, and security teams communicate severity without needing to read the technical writeup first: a 9.8 demands attention today, a 3.1 can wait for the next patch cycle.

Why a shared scoring system exists

Before CVSS, every vendor described severity in its own words — “critical,” “high risk,” “urgent” — with no consistent meaning between them. A “critical” bug from one vendor might be less dangerous than a “high” bug from another. CVSS, maintained by FIRST (the Forum of Incident Response and Security Teams), gives everyone the same vocabulary and the same formula, so a score means the same thing regardless of who assigned it. It shows up everywhere a zero-day vulnerability is disclosed, in bug bounty program payout tiers, and in the CVE entries that vulnerability databases publish daily.

The three metric groups

CVSS builds a score from three groups of metrics:

• Base metrics — the intrinsic, unchanging characteristics of the vulnerability itself: how it’s exploited, what access it grants. This is the score most people mean when they cite “the CVSS score.”
• Temporal/threat metrics — how the vulnerability’s real-world risk shifts over time: whether exploit code is publicly available, whether a patch exists.
• Environmental metrics — how the vulnerability matters to your specific systems: whether the affected asset is internet-facing, whether it holds sensitive data.

Most public CVE listings show only the base score, because temporal and environmental context varies by organization. A security team doing real risk triage is expected to adjust the base score using its own environmental context, not just alphabetize its patch queue by the raw number.

What goes into the base score

Base metrics split into two sub-groups:

Exploitability metrics describe how an attacker reaches and triggers the flaw:

• Attack vector — network, adjacent network, local, or physical. A flaw exploitable over the network from anywhere is far more dangerous than one requiring physical access.
• Attack complexity — low or high, depending on whether exploitation requires specific conditions outside the attacker’s control.
• Privileges required — none, low, or high access needed before the attack can begin.
• User interaction — whether a victim has to do something, like click a link, for the exploit to work.

Impact metrics describe what happens if the attack succeeds, scored separately for confidentiality, integrity, and availability, each rated none, low, or high. A flaw that lets an attacker read data but not modify it scores differently than one that grants full read-write-execute control — the same underlying bug class, like a buffer overflow, can land anywhere on that spectrum depending on what it exposes.

Reading the severity ranges

CVSS scores map to qualitative severity ratings:

Score range	Severity
0.0	None
0.1 – 3.9	Low
4.0 – 6.9	Medium
7.0 – 8.9	High
9.0 – 10.0	Critical

A critical score generally means the flaw is remotely exploitable, requires no privileges or user interaction, and grants high-impact access — the profile of a vulnerability that ends up in mass-exploitation campaigns within days of disclosure.

What CVSS doesn’t tell you

A high CVSS score doesn’t automatically mean a vulnerability is being actively exploited, and a low one doesn’t mean it’s safe to ignore. The score measures theoretical severity based on technical characteristics, not real-world exploitation activity. That’s why serious vulnerability management programs layer in other signals: whether the flaw appears in a known-exploited-vulnerabilities catalog, whether proof-of-concept code is public, and whether the affected system is actually reachable from the internet in your environment.

This is also why environmental scoring matters so much in practice. A 9.8 in a component running on an air-gapped internal tool is a very different priority than the same score in a public-facing login flow. Teams that patch purely by base score, without applying environmental context, tend to burn effort on theoretical risk while real exposure — often tied to weak least-privilege boundaries or supply-chain dependencies — goes unaddressed. See software supply-chain security for how that exposure often enters through dependencies rather than an organization’s own code.

CVSS versions

CVSS has evolved through several major versions (v2, v3.0, v3.1, v4.0), each refining how metrics are defined and scored. Version 3.x introduced the scope metric, capturing whether an exploited component can affect resources beyond its own security boundary — relevant for flaws that escape a sandbox or container. Version 4.0 restructured the metric groups further and added supplemental metrics for things like automatability and recovery difficulty. Vendors don’t always agree on which version to report, so when comparing scores across advisories, check which CVSS version was used — a 3.1 score and a 4.0 score for similar-looking flaws aren’t always directly comparable.

The takeaway

CVSS turns a vulnerability’s technical details into a single number between 0 and 10, built from how it’s exploited (attack vector, complexity, privileges, user interaction) and what it compromises (confidentiality, integrity, availability). It’s a useful common language for triage, but the public base score is only part of the picture — pair it with temporal signals like active exploitation and environmental context about your own systems before deciding what to patch first.