# How to Read a CVSS v4.0 Vector String, Metric by Metric, with Real CVE Records

> A CVSS v4.0 score is only as meaningful as the vector behind it. This guide decodes every metric in a v4.0 vector string, shows how the same flaw scores 8.7 or 9.4 depending on one metric group, and explains why a published score usually assumes the worst case for threat data.

- URL: https://firewallsync.com/posts/how-to-read-a-cvss-v4-0-vector-string-metric-by-metric-with-real-cve-records/
- Site: FirewallSync (https://firewallsync.com/)
- Topic: Security Operations
- Tags: vulnerability management, tools
- Published: 2026-10-17
- Author: Craig Leslie

## Key takeaways

- A CVSS v4.0 vector starts with CVSS:4.0, then lists metrics as NAME:VALUE pairs separated by slashes. The eleven Base metrics are mandatory and must appear in a fixed order. Every other metric is optional and defaults to Not Defined (X).
- A score is only comparable to another score built from the same metric groups. FIRST's specification names them CVSS-B (Base), CVSS-BT (Base and Threat), CVSS-BE (Base and Environmental) and CVSS-BTE (all three).
- Not Defined for Exploit Maturity (E) is scored as if the flaw were Attacked, the worst case. In our recalculation, the general vector of CVE-2026-102489 scored 8.7 with E omitted or set to A, 7.4 with E:P and 6.3 with E:U.
- In a real record, CVE-2026-102489 and CVE-2026-102490 each carry two scores. CVE-2026-102489 scores 8.7 or 9.4 depending only on whether the subsequent-system impacts (SC, SI, SA) are Low or High.
- A v4.0 score and a v3.1 score for the same flaw are not on one scale. CVE-2026-105207 is published as 9.3 under v4.0 and 9.8 under v3.1; both are Critical, but neither is a ranking against the other.



A CVSS v4.0 score such as 9.3 tells you very little until you can read the vector string behind it. This article decodes the string metric by metric, using FIRST's specification and real CVE records published in September and October 2026, and then shows three things that change what a number means: which metric groups were used, which default values were silently applied, and which version produced the score.

**Scope and method.** We read version 1.2 of the [CVSS v4.0 Specification Document](https://www.first.org/cvss/v4.0/specification-document) on October 17, 2026. The example vectors and published scores come from CVE Services records (`cveawg.mitre.org`), read the same day. We recalculated every score with the open-source Red Hat `cvss` Python library (version 3.6). Its results matched all four published v4.0 base scores we checked (9.5, 8.7, 9.4 and 9.3). Scores for modified vectors, such as "what if Exploit Maturity were Unreported", are our own recalculations and are labelled as such. This is research-based analysis, not an independent reimplementation of the scoring formula.

## The short answer: how a vector is built

The specification defines the string like this:

- It begins with `CVSS:4.0`, then each metric follows after a `/` as `NAME:VALUE`, using the abbreviations in the spec (case sensitive).
- All **eleven Base metrics** are mandatory. Threat, Environmental and Supplemental metrics are optional, and an omitted metric is treated as Not Defined (`X`).
- Metrics must appear in the order of the spec's Table 23. "Every other ordering is invalid." A metric may not appear twice.

Here is the spec's own example, with each segment decoded:

`CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N`

| Segment | Metric | Meaning in this example |
|---|---|---|
| `AV:N` | Attack Vector: Network | Exploitable across networks, up to the whole Internet |
| `AC:L` | Attack Complexity: Low | No target-specific circumvention of built-in defenses needed |
| `AT:N` | Attack Requirements: None | Does not depend on special deployment conditions |
| `PR:H` | Privileges Required: High | Attacker needs administrative-level privileges first |
| `UI:N` | User Interaction: None | No other human has to act |
| `VC:L` `VI:L` `VA:N` | Vulnerable system confidentiality, integrity, availability | Low, Low, None |
| `SC:N` `SI:N` `SA:N` | Subsequent system confidentiality, integrity, availability | None: no impact beyond the vulnerable system |

We scored this vector at **5.1 (Medium)**. The spec states the vector but not a score, so that number is ours.

## The Base metrics

**Exploitability metrics** describe the "vulnerable system", the thing that contains the flaw:

| Metric | Values | What it asks |
|---|---|---|
| Attack Vector (AV) | Network (N), Adjacent (A), Local (L), Physical (P) | How far away can the attacker be? Larger reach, higher score |
| Attack Complexity (AC) | Low (L), High (H) | Must the attacker defeat built-in security measures, for example exploit mitigations or by obtaining a target-specific secret? |
| Attack Requirements (AT) | None (N), Present (P) | Does success depend on conditions that arise from deployment, such as a race condition or being on the network path? |
| Privileges Required (PR) | None (N), Low (L), High (H) | What access must the attacker already have? |
| User Interaction (UI) | None (N), Passive (P), Active (A) | Does another person have to take part, and did they have to override a protection? |

**Impact metrics** come in two sets: three for the vulnerable system (VC, VI, VA) and three for any **subsequent system** (SC, SI, SA). The specification says all impacts outside the vulnerable system belong in the subsequent set; if there are none, they are None. Each takes High (H), Low (L) or None (N). This replaces the single "Scope" switch of earlier versions, which the spec calls the property "formerly known as Scope".

Two scoring rules from the spec save arguments. First, Base metrics assume the attacker has "perfect knowledge" of the vulnerability. Second, a specific configuration needed for an attack does not lower the score: the vulnerable system is assessed as if it were in that configuration.

## Worked example 1: a vector with Attack Requirements

**CVE-2026-88771**, a Citrix NetScaler flaw published on September 27, 2026 by NetScaler as the CVE Numbering Authority (CNA, the organization that assigns and describes the record), carries:

`CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H` with a published base score of **9.5 (Critical)**.

Reading it: reachable over the network, low complexity, **but** `AT:P` means success depends on specific deployment conditions, no privileges or user action needed, and High impact on all three properties of both the vulnerable and subsequent systems. We covered the flaw itself in our [NetScaler patch-and-hunt article](/posts/citrix-netscaler-zero-days-cve-2026-88771-cve-2026-88772-patch-and-hunt/). Our recalculation of this vector gave 9.5, the same as the published figure. Note that the record's metric lists Exploit Maturity and the Supplemental metrics as NOT_DEFINED, so this is a Base-only score.

## Worked example 2: one flaw, two scores

**CVE-2026-102489**, a Zammad flaw published on September 30, 2026 by the CNA DIVD, carries two CVSS v4.0 entries in the same record. They differ in exactly one respect: the subsequent-system impacts.

| Entry (scenario label in the record) | SC / SI / SA | Published base score | Our recalculation |
|---|---|---|---|
| General | Low / Low / Low | 8.7 (High) | 8.7 |
| "Chained with CVE-2026-102490" | High / High / High | 9.4 (Critical) | 9.4 |

Both vectors share `AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H` and end in `/E:A/AU:Y/V:C`. A score is therefore a function of assumptions, here whether an attacker can chain the flaw with a second one. That is useful information, but it also means "the CVSS score" for this CVE is not one number. Read the scenario label before you copy a score into a ticket. For context on the flaws, see our [Zammad article](/posts/zammad-zero-days-cve-2026-102489-and-cve-2026-102490-what-is-fixed-and-what-is-not/).

## Threat, Environmental and Supplemental metrics

| Group | Who supplies it | Metrics | Effect on score |
|---|---|---|---|
| Threat | The consumer, from threat intelligence | Exploit Maturity (E): Attacked (A), Proof-of-Concept (P), Unreported (U), Not Defined (X) | Changes it |
| Environmental | The consumer, about their own environment | Security requirements (CR, IR, AR: High, Medium, Low) and Modified Base metrics (MAV, MAC and so on) | Changes it |
| Supplemental | Provider supplies, consumer decides use | Safety (S), Automatable (AU), Recovery (R), Value Density (V), Vulnerability Response Effort (RE), Provider Urgency (U) | **Does not change it** |

Three details matter in practice:

1. **Defaults assume the worst.** The spec says Exploit Maturity `X` "is equivalent to Attacked (A) for the purposes of the calculation" and that Security Requirements `X` equals High.
2. **Supplemental metrics are context only.** The spec says no Supplemental metric has any impact on the final score. `AU:Y`, for example, means attackers can reliably automate all four early kill-chain steps; it does not raise the number.
3. **Environmental metrics can lower or raise a score.** The spec's own example: a system on an isolated network could reduce Attack Vector from Network to Adjacent, and the spec also says it is acceptable to use modified metrics to represent situations that increase the score.

### Our recalculation: what Threat and Environmental choices do

Starting from the Base vector of CVE-2026-105207 (a ZITADEL flaw published October 4, 2026 by the CNA VulnCheck), `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`, published at **9.3**:

| Change we made | Vector suffix | Score (our recalculation) | Rating |
|---|---|---|---|
| None (published Base) | none | 9.3 | Critical |
| Exploit Maturity: Unreported | `/E:U` | 8.1 | High |
| Modified Attack Vector: Adjacent | `/MAV:A` | 8.7 | High |
| Modified Attack Vector: Local | `/MAV:L` | 8.6 | High |

And from the general vector of CVE-2026-102489 with the `E:A`, `AU:Y` and `V:C` segments removed (8.7, High): adding `/E:P` gives **7.4 (High)** and `/E:U` gives **6.3 (Medium)**. Omitting E, or setting it to `A`, leaves the score at 8.7, as the spec's default rule predicts. These are illustrations of how the metric works, not claims that the flaws are unexploited. For CVE-2026-105207, CISA's enrichment in the same record (an SSVC entry timestamped October 6, 2026) lists Exploitation as "none". We did not determine whether that evidence meets the specification's definition of Unreported, so do not treat 8.1 as the right score for that CVE; treat it as the size of the effect.

## Reading the name of the score

The spec requires the label to say which groups were used and says the label "should be used wherever a numerical CVSS value is displayed":

| Name | Metric groups used |
|---|---|
| CVSS-B | Base |
| CVSS-BT | Base and Threat |
| CVSS-BE | Base and Environmental |
| CVSS-BTE | Base, Threat and Environmental |

The spec also notes that providers such as product maintainers and the National Vulnerability Database (NVD) "typically provide only the Base Scores", that is, CVSS-B. By that naming, the entries of CVE-2026-102489 above, which include `E:A`, are strictly Base-plus-Threat scores even though the record field is called `baseScore`. We point this out because a field name in a CVE record does not guarantee which groups the number reflects: read the vector.

## v4.0 versus v3.1: do not compare the numbers

CVE-2026-105207 carries both a v4.0 entry (9.3) and a v3.1 entry (9.8, vector `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`) from the same CNA. The qualitative bands line up (both Critical), and the spec says its score mapping was designed to be backwards compatible with v3.x severity band boundaries. But the v4.0 score comes from a different model: the spec describes expert-ranked groups of vectors called MacroVectors with interpolation inside each one, not the v3.x equations. Compare like with like: v4.0 against v4.0, v3.1 against v3.1, and the band only across versions.

## A small script to check vectors

This reads one vector per line and prints the score or the error. It needs `pip install cvss`:

```python
import sys
from cvss import CVSS4
from cvss.exceptions import CVSSError

for line in sys.stdin:
    vec = line.strip()
    if not vec:
        continue
    try:
        c = CVSS4(vec)
    except CVSSError as e:
        print(f"INVALID  {vec}\n         {e}")
        continue
    print(f"{c.base_score:>4}  {c.severity:<8}  {vec}")
```

We ran it on the vectors in this article. Excerpt of the output:

```
 9.5  Critical  CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
 9.3  Critical  CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
 8.1  High      CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U
INVALID  CVSS:4.0/AV:F/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
         Invalid metric value in CVSS4 vector "AV:F"
INVALID  CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/SC:N/SI:N/SA:N
         Missing mandatory metrics "VA"
INVALID  AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
         Malformed CVSS4 vector "AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N" is missing mandatory prefix or uses unsupported CVSS version
```

The three INVALID vectors are the spec's own invalid examples (bad value, missing mandatory metric, missing prefix). One finding worth knowing: the spec's example of a **mis-ordered** vector is invalid, but when we fed this library a vector that merely swaps `AC` and `AV` it accepted it and returned 6.9 (Medium). So a library accepting a string is not proof the string is spec-valid. If you ingest vectors from many sources, add your own check that the metric order matches Table 23. We tested one library, one version, one swapped pair; we did not test other implementations.

## A practical checklist

1. **Read the prefix.** `CVSS:4.0` and `CVSS:3.1` are different scales.
2. **Read the tail.** Are there Threat (`E:`) or Environmental (`M...`, `CR`, `IR`, `AR`) segments? If so, it is not a Base-only score.
3. **Check the subsequent-system impacts** (`SC`, `SI`, `SA`). They move scores by more than a point in our example and often encode a scenario.
4. **Treat Supplemental segments as notes**, not score drivers.
5. **Record the whole vector** next to the score in your ticket or scanner export, as FIRST requires publishers to give both the score and the vector.
6. **Do not use CVSS as an exploitation signal.** Pair it with [EPSS and KEV](/posts/cvss-vs-epss-vs-kev-which-signal-should-decide-what-you-patch-first/), and see our guide to [reading CISA Vulnrichment SSVC values](/posts/cisa-vulnrichment-how-to-read-ssvc-values-in-a-cve-record-and-turn-them-into-a-patch-decision/).

## Limits of this article

- The CVSS v4.0 specification gives the vector grammar and metric definitions; the exact scoring lookup tables and interpolation are in the specification's later sections, which we did not reproduce or independently reimplement. We rely on one library for recalculation, cross-checked against four published scores.
- Scores for modified vectors are ours and are illustrations. The FIRST online calculator at [first.org/cvss/calculator/4.0](https://www.first.org/cvss/calculator/4.0) is the reference tool; we did not run it for this article.
- The CVE records are as they appeared on October 17, 2026 and can be amended by their CNAs.
- Some CNAs, as in these records, include Threat and Supplemental values in the vector they publish.

## Sources and verification

| Important claim | Source | Verification |
|---|---|---|
| Vector format, mandatory Base metrics, fixed order, optional groups default to Not Defined, example vector and invalid-vector examples | [CVSS v4.0 Specification Document, v1.2](https://www.first.org/cvss/v4.0/specification-document) (read October 17, 2026) | Verified |
| Base metric names, values and definitions; subsequent-system impacts; "formerly Scope" | [CVSS v4.0 Specification Document](https://www.first.org/cvss/v4.0/specification-document) | Verified |
| Exploit Maturity X equals Attacked; Security Requirements X equals High; Supplemental metrics do not change the score | [CVSS v4.0 Specification Document](https://www.first.org/cvss/v4.0/specification-document) | Verified |
| Nomenclature CVSS-B, -BT, -BE, -BTE; NVD and maintainers typically provide Base scores only | [CVSS v4.0 Specification Document](https://www.first.org/cvss/v4.0/specification-document) | Verified |
| Scoring via MacroVectors and interpolation; backwards-compatible severity bands | [CVSS v4.0 Specification Document](https://www.first.org/cvss/v4.0/specification-document) | Verified |
| CVE-2026-88771: published September 27, 2026; vector and 9.5 | [CVE Services record](https://cveawg.mitre.org/api/cve/CVE-2026-88771) | Verified |
| CVE-2026-102489: published September 30, 2026; two entries, 8.7 and 9.4, differing in SC/SI/SA; scenario label | [CVE Services record](https://cveawg.mitre.org/api/cve/CVE-2026-102489) | Verified |
| CVE-2026-105207: published October 4, 2026; v4.0 9.3 and v3.1 9.8 vectors; SSVC Exploitation "none" | [CVE Services record](https://cveawg.mitre.org/api/cve/CVE-2026-105207) | Verified |
| Recalculated scores (5.1, 6.3, 7.4, 8.1, 8.6, 8.7) and the swapped-order result (6.9) | Our run of the Red Hat `cvss` library v3.6, October 17, 2026 | Qualified: our computation, one library; published scores matched on four records |
| Choice of E:U as an appropriate rating for any specific CVE | Not asserted | Qualified: illustration only |

## Frequently asked questions

### What does a CVSS v4.0 vector string look like?

It looks like CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. The prefix names the version, and each segment is an abbreviated metric and value. FIRST's specification requires the eleven Base metrics and a fixed metric order.

### What is the difference between CVSS-B and CVSS-BTE?

CVSS-B is the Base score alone. CVSS-BTE also uses Threat metrics (such as Exploit Maturity) and Environmental metrics (such as security requirements and modified base metrics). The specification says the label should accompany any displayed numeric score so readers know which metric groups were used.

### Why is my scanner's CVSS score higher than my own assessment?

A published Base score assumes the worst case for Threat and Environmental data. The specification says unset Exploit Maturity is treated as Attacked, and unset security requirements are treated as High. If you have evidence that lowers either, a recalculated score can be lower.

### Is a CVSS v4.0 score of 9.3 worse than a v3.1 score of 9.8?

Not necessarily. The versions use different metrics and different scoring methods, so the numbers are not directly comparable. Compare v4.0 with v4.0, and use the qualitative rating (Critical, High and so on) only as a rough bridge.

### Does a high CVSS score mean a vulnerability is being exploited?

No. CVSS describes severity under stated assumptions. Exploitation evidence comes from other sources, such as CISA's Known Exploited Vulnerabilities catalog or the EPSS probability model. See our comparison of CVSS, EPSS and KEV.


Image credit: Photo by [Launde Morel](https://unsplash.com/photos/4VSsq9ErzOs) on Unsplash