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 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.

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 (attack vector, attack complexity, privileges required, user interaction) and what it affects (the impact on confidentiality, integrity, and availability). 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, which most organizations never fill in.

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. 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.

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 from August 2026 make the gap concrete. Oracle WebLogic CVE-2026-21962 carries a CVSS of 10.0 and, critically, 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 on August 25, 2026 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 having 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 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

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 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?.