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

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

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:

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

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.

Threat, Environmental and Supplemental metrics

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:

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”:

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:

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, and see our guide to reading CISA Vulnrichment SSVC values.

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

Vulnerability ManagementTools