The Common Vulnerability Scoring System (CVSS) is an open standard for rating how severe a software vulnerability is, on a scale from 0.0 to 10.0. It is maintained by FIRST, the Forum of Incident Response and Security Teams, and it is the number you see next to almost every CVE. A CVSS score describes how bad a flaw would be if it were exploited, based on its technical characteristics. It does not tell you how likely it is to be exploited, or how much it matters to your organisation. Those are separate questions, and treating the score as the answer to them is one of the most common mistakes in vulnerability management.
This guide explains how CVSS scores are built, what changed in version 4.0, and how to use them alongside the signals that predict real attacks.
The severity bands
CVSS v3.1 and v4.0 use the same qualitative bands:
- None: 0.0
- Low: 0.1 to 3.9
- Medium: 4.0 to 6.9
- High: 7.0 to 8.9
- Critical: 9.0 to 10.0
Vendors don't have to use these labels. Microsoft, for example, publishes its own severity rating (Critical, Important, Moderate, Low) next to the CVSS score, and the two don't always line up.
How a CVSS score is built
A score comes from a set of metrics, each with a few possible values. The combination is written as a vector string, and a formula turns the vector into a number. The vector is more useful than the number, because it tells you why a flaw scored the way it did.
Base metrics: the flaw itself
The base metrics describe the vulnerability in isolation and are what vendors and the National Vulnerability Database publish. In CVSS v3.1 they are:
- Attack Vector (AV): Network, Adjacent, Local or Physical. How close does the attacker need to be?
- Attack Complexity (AC): Low or High. Does the attack depend on conditions the attacker can't control?
- Privileges Required (PR): None, Low or High.
- User Interaction (UI): None or Required. Does someone have to click, open or approve something?
- Scope (S): Unchanged or Changed. Can the attack reach beyond the vulnerable component, for example from a virtual machine to its host?
- Confidentiality, Integrity and Availability (C, I, A): None, Low or High for each.
Two worked examples
Log4Shell (CVE-2021-44228) scored the maximum: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, which is 10.0. Reachable over the network, easy, no credentials, no user, and complete control.
Now take a flaw that is reachable over the network but needs a user to open something, and that leaks confidential data without changing or breaking anything: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. That scores 6.5, a Medium. A credential leak, such as an application handing a user's password hash to an attacker's server, often lands here.
Temporal or threat metrics: what is happening now
CVSS v3.1 has temporal metrics, including Exploit Code Maturity, that can lower a score while no exploit exists. Version 4.0 simplifies these into threat metrics, chiefly Exploit Maturity: whether exploitation is attacked, proof-of-concept or unreported. Few published scores include them, because they change over time and the base score is what gets copied around.
Environmental metrics: your estate
Environmental metrics let you adjust a score for your organisation: how important confidentiality, integrity and availability are for the affected system, and whether your own controls change the attack. A flaw in a test server and the same flaw in your payroll system have the same base score. They shouldn't have the same priority, and environmental metrics are how CVSS expects you to express that.
What changed in CVSS 4.0
FIRST released CVSS v4.0 in November 2023. The main changes:
- New nomenclature. Scores are labelled by what went into them: CVSS-B (base only), CVSS-BT (base and threat), CVSS-BE (base and environmental) and CVSS-BTE (all three). That makes it clear when you are looking at a bare base score.
- Attack Requirements (AT) is a new base metric for conditions in the target's deployment that the attack depends on, separate from Attack Complexity.
- User Interaction is now None, Passive or Active, separating "the user visited a page" from "the user had to do something deliberate".
- Scope is gone. Instead, impact is scored separately for the vulnerable system and for subsequent systems, which is clearer for flaws that break out of a sandbox or a VM.
- Supplemental metrics such as Automatable, Recovery and Safety add context without changing the score.
Both versions are in use. NVD and many vendors still publish v3.1 scores, so expect to see both for some time.
Why a 6.5 can matter more than a 9.9
Microsoft's November 2026 release is a good illustration. Its highest-scoring flaw was a SharePoint Server elevation of privilege at CVSS 9.9, which Microsoft rated "Exploitation Less Likely". The only bug known to be exploited was an Outlook flaw scored 6.5 and rated Moderate, which leaks users' NTLMv2 hashes. Attackers were already using the 6.5. Our write-up of that release goes through how we'd prioritise it.
The lesson is that CVSS measures severity, not risk. Risk also depends on whether someone is exploiting the flaw, whether your exposed systems have it, and what those systems hold. A patch queue sorted by CVSS alone puts thousands of high scores ahead of the handful of bugs being used against organisations like yours.
Signals to use alongside CVSS
- CISA's Known Exploited Vulnerabilities (KEV) catalogue. A list of CVEs with evidence of exploitation in the wild. If a CVE is on it, patch it first, whatever its score.
- EPSS. FIRST's Exploit Prediction Scoring System estimates the probability that a CVE will be exploited in the next 30 days, based on observed activity. It answers the question CVSS doesn't.
- Vendor exploitability ratings. Microsoft's Exploitability Index labels each CVE as "Exploitation Detected", "More Likely" or "Less Likely". It is short-term guidance, but useful within a release.
- Your own context. Is the system internet-facing? Does it hold credentials or sensitive data? Is it a domain controller, a VPN appliance or a hypervisor? Edge and identity systems deserve a shorter deadline at any score.
We wrote about this approach in more depth in 1,413 CVEs in one month, and our guide to the vulnerability management lifecycle covers where prioritisation fits.
Frequently asked questions
Who assigns CVSS scores?
Usually the vendor or the CVE Numbering Authority that publishes the CVE. NIST's National Vulnerability Database may publish its own score as well, and the two sometimes differ. When they do, read both vector strings to see which assumption differs.
What is a good CVSS score?
There isn't one. CVSS rates vulnerabilities, not systems. A lower score means a less severe flaw in theory, but an exploited Medium can be more urgent than an unexploited Critical.
Is CVSS 4.0 replacing 3.1?
Gradually. Version 4.0 is the current standard and more organisations publish it each year, but v3.1 scores are still the most common in vendor advisories and scanners. Many tools show both.
Should I set patching deadlines by CVSS score?
Use CVSS as one input. A common approach is to set the shortest deadline for anything in KEV or with a high EPSS score, then use CVSS and asset importance to order the rest. Internet-facing systems should get shorter deadlines than internal ones.
Does a low CVSS score mean I can ignore a vulnerability?
No. Low-scored flaws are often chained with others, and some, like credential leaks, score low because the damage happens in a later step that the score doesn't capture.
How Wizard Cyber helps
Our vulnerability and patch management service turns monthly releases into a short list ordered by exploitation and exposure, not by score alone. Our offensive security team shows which vulnerabilities in your estate an attacker could actually use, and our SOCs, staffed 24/7, watch for the exploitation that happens before patches are applied.
If your patch queue is ordered by CVSS and still never seems to get shorter, book a demo or talk to our team.