What Is CVSS? CVSS Score and Metrics Explained

CVSS, the Common Vulnerability Scoring System, is an open, vendor-neutral standard that rates the technical severity of a software vulnerability on a scale from 0.0 to 10.0, where higher means more severe. It is maintained by FIRST (the Forum of Incident Response and Security Teams) and used by the National Vulnerability Database (NVD), vendors, and scanners to give every CVE a comparable severity number. A CVSS score answers one question: how bad is this flaw in the abstract, before you factor in whether anyone is actually exploiting it in your environment.

Understanding what is CVSS, and just as importantly what it does not measure, is the foundation of sane vulnerability prioritization. The score is built from a base metric group that captures how a vulnerability can be exploited and what it affects, expressed as a compact vector string and a single number from 0 to 10. FIRST publishes the specification openly, and the NVD assigns a base score to most CVEs, which is why the same number shows up across tools like Tenable, Qualys, and Rapid7.

What do CVSS scores and severity ratings mean?

Under CVSS v3.1, the 0.0 to 10.0 number maps to a qualitative severity rating so teams can triage at a glance. The bands below are defined by FIRST and used verbatim by the NVD. A score of 9.0 or above is Critical, the tier reserved for flaws that are both easy to exploit and highly damaging, such as an unauthenticated remote code execution bug.

The base score is deliberately context-free: it assumes a reasonable worst case and does not know whether the affected system sits on your internet edge or on an air-gapped lab bench. That is by design. CVSS gives you a stable, comparable severity signal, and leaves the environmental adjustment to you through its optional Temporal and Environmental metric groups.

What are the CVSS base metrics?

The base score is calculated from eight metrics split into two halves: exploitability metrics, which describe how hard the vulnerability is to attack, and impact metrics, which describe the damage. These are the values the NVD sets for each CVE, and together they produce the 0 to 10 base number.

The worst case on every axis, a network-reachable flaw needing no privileges and no user interaction, with high impact to confidentiality, integrity, and availability, is what drives a score toward 10.0. Attack Vector is the single most influential exploitability metric, which is why remote, unauthenticated bugs dominate the Critical tier.

What is CVSS scope, and why does it matter?

Scope captures whether a vulnerability's impact stays inside the component that contains the flaw or spills into other components under a different security authority. If exploiting a bug in one sandboxed process lets an attacker affect the host operating system or other tenants, Scope is Changed, which raises the score. A VM escape or a hypervisor breakout is the classic Scope: Changed case, because the impact crosses the isolation boundary the system was built to enforce. Scope: Unchanged means the damage is confined to the vulnerable component itself.

How do you read a CVSS vector string?

A CVSS vector string is a compact, machine-readable summary of every metric that produced the score, so two engineers can see exactly why a CVE rates what it does. It begins with the version prefix and lists each metric as an abbreviation. Reading it left to right tells you the full exploitability and impact profile at a glance.

The example CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H is a textbook CVSS 9.8, an unauthenticated, network-exploitable flaw with total impact, which is the profile of most critical remote code execution CVEs.

What are the CVSS base, temporal, and environmental metric groups?

CVSS defines three metric groups, and most CVEs publish only the first. The Base group is the intrinsic, context-free severity described above and is what almost everyone means by "the CVSS score." The Temporal group (renamed the Threat group in v4.0) adjusts for factors that change over time, such as whether exploit code exists and whether a fix is available. The Environmental group lets you re-score a vulnerability for your own environment, weighting the confidentiality, integrity, and availability requirements of the specific asset and adjusting for compensating controls. The CVSS environmental score is the mechanism CVSS provides for local context, and it is powerful but rarely filled in, which is why published scores stay context-free.

What is the difference between CVSS v3.1 and v4.0?

CVSS v3.1 is the version still attached to the vast majority of CVEs, while CVSS v4.0, released by FIRST on November 1, 2023, is the current standard being adopted gradually. The headline change in v4.0 is finer granularity and less over-reliance on a single base number. It splits the old base score into clearer nomenclature (CVSS-B, CVSS-BT, CVSS-BTE), adds a Threat metric group in place of the old Temporal one, introduces Supplemental metrics like Automatable and Recovery, and improves how it scores vulnerabilities in OT, ICS, and safety-critical systems.

In practice you will see both versions for years. The NVD records v3.1 for older entries and increasingly carries v4.0 vectors for newer ones, so a modern vulnerability feed often shows a CVSS:4.0 vector string alongside the familiar CVSS:3.1 one. The severity bands (None through Critical) are the same across both.

What is a CVSS 10.0 score?

A CVSS 10.0 is the maximum possible score, meaning the vulnerability is worst-case on the metrics that matter most: typically network-reachable, requiring no privileges and no user interaction, with high impact and, often, a changed scope. A 10.0 is the rare top of the Critical band (9.0 to 10.0) and should be treated as a drop-everything patch, especially if the flaw is also in CISA KEV or has a high EPSS score. That said, a 10.0 still measures severity, not certainty of attack, so the same caveat below applies even at the ceiling.

Why is a high CVSS score not the same as high risk?

Because CVSS measures severity, not likelihood of exploitation, and the two diverge constantly. A CVSS 10.0 with no working exploit and no internet exposure may be less urgent than a CVSS 6.9 that attackers are actively using. This is the single most important thing to internalize about the score, and it is why serious prioritization pairs CVSS with two other data sources: EPSS, which estimates the probability a flaw will be exploited, and the CISA KEV catalog, which lists vulnerabilities with confirmed real-world exploitation.

Two live examples make the gap concrete. Oracle WebLogic CVE-2026-21962 carries a CVSS of 10.0 and sits in CISA KEV with an EPSS in the 98.6th percentile, so severity and real-world risk agree: patch now. But Gitea CVE-2026-60004, rated 9.8 by the vendor, had no NVD-assigned base score at all when CISA added it to KEV after active exploitation, a reminder that the KEV listing, not the CVSS number, was the signal that mattered. Kernel and local-privilege-escalation bugs show the inverse: many carry modest CVSS scores and low EPSS percentiles despite reliable public exploits, because the score underweights local access.

How should teams actually use CVSS?

Use CVSS as the first filter, never the last word. It is excellent for what it is designed to do: give every CVE a comparable, transparent severity baseline that any tool in your stack will agree on. The mistake is treating "patch everything 9.0 and above" as a strategy, which floods teams with work while missing the mid-scored bug that is being exploited today.

A defensible workflow layers three signals. Start with CVSS to gauge technical severity, overlay EPSS to weigh exploitation likelihood, and treat any CVE in CISA KEV as an automatic top priority regardless of its base score. Then add the context CVSS cannot see: is the asset internet-facing, does it hold regulated data, is a compensating control in place. Our own analysis of 2025 found that 67 percent of the year's actively exploited vulnerabilities would have been missed by a single annual assessment, with a median gap of 26 days between disclosure and exploitation, which is exactly the window a CVSS-only, once-a-year approach leaves open.

Frequently asked questions

What does CVSS stand for? CVSS stands for the Common Vulnerability Scoring System. It is an open standard maintained by FIRST for rating the severity of security vulnerabilities on a 0.0 to 10.0 scale.

How is a CVSS score calculated? A CVSS base score is computed from eight base metrics (attack vector, attack complexity, privileges required, user interaction, scope, and the confidentiality, integrity, and availability impacts) using the formula in the FIRST specification. FIRST publishes an online calculator that turns a vector string into the number.

Is a CVSS score of 9.8 bad? Yes. Any score of 9.0 or higher is rated Critical, and 9.8 typically means an unauthenticated, network-reachable flaw with severe impact. It should be patched on your fastest track, especially if the CVE is also in CISA KEV or has a high EPSS score.

Who assigns CVSS scores? The standard is maintained by FIRST. Base scores are assigned by the NVD and by CNAs (CVE Numbering Authorities), which include many vendors. Because scoring involves judgment on the metrics, a vendor score and the NVD score can occasionally differ.

What does a CVSS score of 0 mean? A score of 0.0 maps to the None severity rating, meaning the issue has no measurable security impact under CVSS. It does not necessarily mean "not a bug," only that it does not register as a security-relevant vulnerability on the scale.

Is CVSS enough for prioritization? No. CVSS measures severity, not exploitation likelihood or business context. Pair it with EPSS (exploitation probability) and the CISA KEV catalog (confirmed exploitation), then adjust for your own asset exposure.

Our read

CVSS is a shared language for severity, and that is genuinely valuable: without it, every vendor would grade danger differently. The failure mode is mistaking the language for the whole conversation. Severity is one axis; exploitation likelihood and your own exposure are the others, and a number computed in a vacuum cannot know them. That is why the verifiable-by-design approach treats CVSS as an input to continuous verification rather than a verdict, confirming which of your assets actually expose a given flaw and whether it is being exploited, rather than sorting a spreadsheet by base score once a quarter. Score first, then verify what the score cannot see.

Severity bands, metric definitions, and version detail per FIRST.org and the NVD; exploitation status per CISA KEV. Sources linked above.

Related: What CVSS misses: EPSS, KEV, and patch prioritization, What is EPSS?, and What is the CISA KEV catalog?.