What a CVSS score means: how to read a vector string, and why a 10.0 is not the same as risk

In short

A CVSS score is a number from 0.0 to 10.0 that rates how severe a software vulnerability is, based on how it can be attacked and what an attacker gains. It does not say how likely you are to be attacked or how much your own systems are at risk, and a vendor's score usually covers only the "Base" metrics. Use it to sort the pile, then add two more questions: is it being exploited, and is the vulnerable thing exposed in your environment?

Why you keep seeing it

When GitLab fixed CVE-2026-110264, its advisory carried "CVSS 10.0" and a string that begins CVSS:3.1/AV:N/AC:L/PR:N/UI:N. Security advisories, scanners, bug bounty reports and news stories all quote these numbers. This guide explains what the number and the string mean, how to read one yourself, and where it stops being useful.

The Common Vulnerability Scoring System is maintained by FIRST, the Forum of Incident Response and Security Teams. There are two versions in common use: 3.1 and 4.0. The score bands are the same in both.

The five bands

FIRST's specifications for both versions define the same qualitative ratings:

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

FIRST says using these labels is optional, and that they are meant to help organisations assess and prioritise. The label is a convenience, not a verdict.

Reading a vector string (CVSS 3.1)

The score is calculated from a set of answers called metrics, and the vector string is a compact record of those answers. Here is the string GitLab published for CVE-2026-110264, split up:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

The first eight metrics are the "Base" group:

• AV, Attack Vector. How remote can the attacker be? N is Network (reachable over the internet or a network), A is Adjacent, L is Local, P is Physical. FIRST's text says the value is larger the more remote an attacker can be, because more potential attackers can reach it.
• AC, Attack Complexity. L (Low) means the attack can be repeated at will; H (High) means it depends on conditions outside the attacker's control. FIRST says specific configurations required for an attack are scored as if the target is in that configuration.
• PR, Privileges Required. N (None), L (Low, an ordinary account) or H (High, an administrator).
• UI, User Interaction. N or R (Required: someone must click, open or approve something).
• S, Scope. U (Unchanged) means the vulnerable component and the impacted component are managed by the same security authority. C (Changed) means exploitation can affect resources beyond that authority, such as an escape from a sandbox or a container.
• C, I and A, Confidentiality, Integrity and Availability. How much of each is lost: N (None), L (Low) or H (High).

Read left to right, the GitLab string says: reachable over the network, easy to repeat, no account needed, nobody has to click anything, it can affect more than the component itself, and it can lose everything on all three counts. That is the combination that scores 10.0.

Compare it with another flaw from the same GitLab release, CVE-2026-15723, whose published vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N and score 8.2. The attacker needs a low-privilege account (PR:L), the attack is harder to pull off (AC:H), and availability is not hit (A:N). It is still "High", but it is clearly a different kind of problem, and the vector tells you why in a second. GitLab says it applies only when both SAML and LDAP auto-linking are enabled, which is the sort of condition AC:H is meant to capture.

You can verify any published score yourself with FIRST's free online calculator on first.org, which takes a vector string and returns the number.

What changed in CVSS 4.0

Version 4.0 is a revision, not a different idea, but several things matter when you read advisories:

• Attack Requirements (AT) was added. FIRST describes it as capturing the deployment and execution conditions of the vulnerable system that enable the attack. It separates "the attack is hard" (Attack Complexity) from "the attack only works in certain setups".
• Scope is gone. Version 4.0's base metrics distinguish the vulnerable system from subsequent systems that are affected, instead of using one Scope switch.
• Labels now say which metrics were used. FIRST's specification asks that a score be written with a name: CVSS-B for Base metrics only, CVSS-BT for Base and Threat, CVSS-BE for Base and Environmental, and CVSS-BTE for all three. It says the nomenclature should be used wherever a numerical CVSS value is displayed. The "Temporal" group of 3.1 became "Threat" in 4.0, and there is also a Supplemental group.
• Scores from different versions are not interchangeable. A 3.1 score and a 4.0 score for the same bug can differ, so a score is only meaningful with its version, which is why the vector string starts with the version.

The part most people skip: Base is not risk

FIRST's own nomenclature page makes the central point: numerical scores "have very different meanings based on the metrics used to calculate them", and the usefulness of a score for prioritisation depends on the metrics behind it. It also says applying Threat and Environmental metrics is the responsibility of whoever consumes the score, while assessment providers such as product maintainers and the National Vulnerability Database typically supply Base scores.

So the number in a vendor advisory is a statement about the flaw in the abstract. It cannot know whether the vulnerable service is on the internet in your network or only in a test lab behind a firewall, whether a working exploit is circulating, or whether your data is of much value. Three consequences follow:

1. A 10.0 on something you do not run is not urgent, and a 6.5 on your public login page might be. The Environmental group exists for exactly this, but few teams fill it in.
2. Two flaws with the same number can be very different. An unauthenticated network flaw and a flaw needing an administrator can both reach "High" through other metrics.
3. The score says nothing about whether anyone is attacking. For that you need other signals.

Two signals to pair with it

Exploitation: CISA's KEV catalogue. CISA's Known Exploited Vulnerabilities catalogue lists vulnerabilities exploited in the wild, and CISA's page says organisations should use it as an input to their vulnerability-management prioritisation. A vulnerability being in the catalogue is a stronger reason to hurry than its score. In recent weeks we covered cases of that kind, such as ransomware groups exploiting a PAN-OS flaw and several Plex Media Server flaws used to install miners. Note the limits: KEV is a yes/no list of confirmed cases, and a bug absent from the list may simply not have been observed yet. Of the GitLab flaw, The Hacker News said it was not in the catalogue as of 22 October.

Likelihood: EPSS. The Exploit Prediction Scoring System, maintained by a FIRST special interest group, is described by FIRST as a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days, published as a number from 0 to 1. It answers a different question than CVSS: not "how bad if exploited" but "how likely is exploitation soon". Cut-off values you may see in blog posts (for example 0.1 or 0.5) are individual heuristics, not official thresholds.

Put together, each answers one question:

Signal	Question it answers
CVSS Base	How bad could this be in general?
CVSS Threat/Environmental	How bad is it for a known exploit situation and for our setup?
EPSS	How likely is exploitation in the next 30 days?
KEV	Is it already being exploited?

A practical routine

1. Start with what you actually run. Match advisories to your inventory (a software bill of materials helps). A flaw in something you do not run needs no action.
2. Check KEV first. Anything listed there and present in your estate goes to the top.
3. Use CVSS to rank the rest, and read the vector, not just the number. Network, no privileges, no interaction is the pattern to worry about.
4. Add exposure. Is the system reachable from the internet? If it is internal-only, an attacker needs a foothold first. Record this as your Environmental view.
5. Use EPSS to break ties among similar scores.
6. Write the version and metric names down: "CVSS 3.1 Base 9.8" or "CVSS-BT 4.0 8.7", not "9.8".

Common mistakes

• Treating Critical as a synonym for "being attacked".
• Comparing a 3.1 score to a 4.0 score.
• Assuming a flaw without a score yet is a minor one.
• Ignoring the vector, and so missing that a 9.9 needs a logged-in account while a 9.8 does not. Under 3.1, a network flaw that needs no account and leaves Scope unchanged scores 9.8, while one that needs a low-privilege account but changes Scope scores 9.9; the numbers are close but the situations are not.

Sources

• CVSS v3.1 Specification Document (FIRST)
• CVSS v4.0 Specification Document (FIRST)
• Exploit Prediction Scoring System (EPSS) (FIRST)
• Known Exploited Vulnerabilities Catalog (CISA)
• GitLab Critical Patch Release 19.5.1 (GitLab, vectors and scores used as examples)
• Critical GitLab Flaw (CVSS 10.0) Could Allow Unauthenticated RCE (The Hacker News)