CVSS Vector Strings Explained: 3.1 vs 4.0 (2026)

CVSS Vector Strings Explained: 3.1 vs 4.0 (2026)

A CVSS score is one number. The vector string is the argument behind it. Two advisories can print the same 9.8 for very different reasons, and two analysts can print different numbers for the same bug. The vector tells you why.

Need the parse, not the lecture? Paste a vector into the free CVSS Vector Parser. It expands every metric of a 3.1 or 4.0 string into plain English and computes the 3.1 base score. For 4.0 it doesn't invent a number; it points you to the official calculator. Below is what that page can't fit: the grammar rules, Scope done properly, what 4.0 changed, and real NVD records where the numbers disagree.

This is defensive triage and reporting. Every CVE vector below was copied from its NVD record on 6 October 2026, and every 3.1 score was recomputed from FIRST's published equations. No exploitation detail for any CVE.

The grammar of a vector string

The CVSS v3.1 specification (Section 6) defines the shape: the label CVSS:, the version 3.1, then metrics, each preceded by a slash. Each metric is an abbreviated name, a colon, and an abbreviated value. AV:N is Attack Vector: Network.

Four rules carry over to CVSS v4.0:

• Every Base metric must be present.
• Every other group is optional. An omitted metric counts as Not Defined (X).
• You may write X explicitly.
• The same metric must not appear twice.

Order is where the versions split. In 3.1, a vector should follow the spec's table order, "though other orderings are valid," and readers "must accept metrics in any order." The spec's own example is shuffled: CVSS:3.1/S:U/AV:N/AC:L/PR:H/UI:N/C:L/I:L/A:N/E:F/RL:X. In 4.0, a vector "must contain metrics in the order shown in Table 23, every other ordering is invalid." Abbreviations are case sensitive too; a lowercase ui is on the spec's invalid list.

The optional X shows up on live records. For CVE-2024-0012, NVD's page shows Palo Alto Networks' 4.0 vector ending .../SC:L/SI:N/SA:N/AU:N/R:U/V:C/RE:H/U:Red. NVD's API data spells out every Threat and Environmental metric as X: E:X/CR:X/IR:X/AR:X/MAV:X/.... Same vector, two spellings.

Decoding the one everyone has seen

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

NVD's primary 3.1 score for CVE-2022-22965 (Spring4Shell) is exactly this vector, shown as 9.8 Critical. I ran it through the spec's equations. The impact sub-score is 0.914816, Impact is 5.873119, Exploitability is 3.887043. They sum to 9.760162, and Roundup takes that to 9.8.

Roundup isn't normal rounding. It returns the smallest one-decimal number equal to or higher than its input, so Roundup(4.02) is 4.1. Naive floating-point code gets this wrong; Appendix A gives an integer-arithmetic version, and my calculator uses it.

The 3.1 Base metrics, in plain words

AV. Network, Adjacent, Local, Physical. The more remote the attacker, the higher the score. The spec says to use Network even if the attacker must be on the same corporate intranet.

AC. Conditions beyond the attacker's control. Low means repeatable success. High covers gathering target-specific secrets, winning a race condition, or sitting in the network path. User interaction is excluded. CVE-2024-6387 in OpenSSH's server is a clean example: NVD's description names a race condition, and both NVD and Red Hat show CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. I get 8.1 High from the equations, matching both.

PR. Privileges needed before exploiting. Usually None for hard-coded credentials and social-engineering bugs such as reflected XSS or CSRF.

UI. None or Required. Must a human other than the attacker take part?

C, I, A. High, Low, None. Score the final, "end game" impact, and only what the attacker gains.

Scope, done properly

This is the metric I see misread most in reports. The spec builds it on a security authority: whatever enforces access control, such as an application, an OS, firmware, or a sandbox. Everything under one authority is one security scope. If exploiting the vulnerable component impacts something under a different authority, Scope is Changed.

The 3.1 User Guide gives cases. A VM bug that reads or deletes host files: Changed. XSS, where a web app flaw hits users' browsers: Changed. Crashing a web or SSH server: not Changed, since users aren't components. SQL injection into a database sharing the app's credentials: usually not Changed.

Setting S:C moves the math in three places. Impact uses a different formula. Privileges Required gets heavier weights (Low 0.62 to 0.68, High 0.27 to 0.5). And the sum is multiplied by 1.08 before the cap at 10.

Same everything, flip only S:

Identical C/I/A, different band. Those two are illustrative, not a CVE. For a real one, NVD's primary score for CVE-2021-44228 (Log4Shell) is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H at 10.0: the canonical 9.8 vector with S:C. Uncapped, the formula gives about 10.73; Minimum(..., 10) holds it at 10.0.

The severity bands

Both specs use the same scale, and FIRST calls the ratings optional:

What changed in CVSS 4.0

The 4.0 User Guide lists the changes. In the order they'll trip you:

AC was split into AC and AT. In 3.1, evading ASLR and retrying a race condition earned the same AC:H penalty. In 4.0, Attack Complexity means evading security-enhancing defences, such as ASLR or DEP bypass, or obtaining a target-specific secret. Attack Requirements (AT:N or AT:P) covers deployment and execution conditions; the spec's AT:P examples are a race condition that must be won and on-path network injection.

Scope is gone. VC/VI/VA covers the vulnerable system, SC/SI/SA any subsequent system. No impact outside? The subsequent metrics stay N.

User Interaction got a middle value. None, Passive, Active. Passive is limited, involuntary interaction; the spec puts most stored XSS here. Active is a conscious action or subverting a protection, like reflected or self XSS.

Temporal became Threat. Remediation Level and Report Confidence are retired. Exploit Maturity takes Attacked, Proof-of-Concept, Unreported, or Not Defined, and E:X is scored as Attacked.

Supplemental metrics are new. Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency. None of them changes the score.

Scores get labels. CVSS-B is Base only; CVSS-BT adds Threat, CVSS-BE adds Environmental, CVSS-BTE has all three. Providers such as NVD typically publish CVSS-B.

The score is no longer a formula. FIRST grouped the 15 million possible BTE vectors into 270 equivalence sets, experts ranked them, and a score comes from a MacroVector lookup table plus interpolation. That's why the Andrax parser explains a 4.0 vector but hands the number to FIRST's calculator.

A real 4.0 vector, from CVE-2024-0012, scored by Palo Alto Networks as the CNA:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:N/SA:N/AU:N/R:U/V:C/RE:H/U:Red

Network, low complexity, no requirements, privileges or user. High impact on the vulnerable system, low confidentiality impact on a subsequent one. Then Supplemental: not automatable, user-driven recovery, concentrated value, high response effort, Provider Urgency Red. NVD labels it CVSS-B 9.3 Critical. Five Supplemental metrics, still CVSS-B.

Severity is not priority

FIRST says it in both user guides. The 4.0 guide's heading is "CVSS Base Score (CVSS-B) Measures Severity, not Risk." Base scores "should not be used alone to assess risk," while CVSS-BTE "can be considered much closer to 'Risk'."

Here's a real pair. CVE-2024-9474 is a PAN-OS privilege escalation that needs a PAN-OS administrator to begin with. Palo Alto's 4.0 vector carries PR:H, and NVD shows it as CVSS-B 6.9 Medium. NVD's 3.1 vector, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, scores 7.2 High; I checked it with the equations. Now CVE-2024-0012's NVD description: that authentication bypass gives an unauthenticated attacker PAN-OS administrator privileges, or lets them "exploit other authenticated privilege escalation vulnerabilities like CVE-2024-9474." Both have been in CISA's Known Exploited Vulnerabilities catalog since 18 November 2024, flagged for known ransomware use. A Medium behind a Critical, both exploited, is not a Medium for patching.

CISA says organizations "should use the KEV catalog as an input to their vulnerability management prioritization framework." Input, not override.

How the other groups move a number:

• 3.1 Temporal can only hold or lower. Every Temporal constant in Table 16 is 1 or less.
• 3.1 Environmental can go either way. Security Requirements weigh High at 1.5 and Low at 0.5, and Modified metrics override Base values.
• 4.0 starts at the worst case. E:X counts as Attacked, and CR/IR/AR default to High. Threat intelligence is used to reduce CVSS-BTE. Modified Base metrics can push either way.

The pentest vs vulnerability scanning guide makes this its own lifecycle step: scanners hand you CVSS, you add business context before prioritizing.

Reading vectors in the wild, and the mistakes I keep seeing

Vectors turn up on NVD, in vendor advisories, scanner output and pentest reports. The penetration testing checklist lists a CVSS score among each finding's fields. FIRST is stricter: publish both the score and the vector, so others can see how the score was derived. In my reports the vector sits on the same line as the number. The pentest methodology guide maps CVSS ranges to severity; the vector makes that mapping auditable.

Mistake 1: assuming NVD and the vendor agree. CVE-2023-4966 (Citrix NetScaler ADC and Gateway) shows two 3.1 vectors on NVD:

The whole gap is Integrity and Availability. NVD's description says "sensitive information disclosure," which matches the C-only reading; the vendor's vector also scores I and A. Don't average them. Decide which impact matches your deployment.

Mistake 2: comparing across versions. CVE-2024-0012 shows 9.3 (4.0, CVSS-B, from the CNA) and 9.8 (3.1, from NVD). Put the version and label next to any number you quote.

Mistake 3: pasting a 3.1 vector into a 4.0 tool. It's missing AT and the VC...SA set, and in 4.0 S is the Supplemental Safety metric, valued X, N or P. So S:U means nothing there, and UI:R isn't a 4.0 value. A strict parser rejects it; a sloppy one misreads it. Check the prefix first.

Mistake 4: forcing CVSS onto smart-contract bugs. My Immunefi bug report tutorial puts it plainly: NIST CVSS is a poor fit for most DeFi reports. Use Immunefi's severity classification, then the program's listed impacts.

FAQ

What is a good CVSS score?

There isn't one. The scale measures severity. A lower Base score means lower intrinsic severity, nothing more: CVE-2024-9474 is a Medium under 4.0 and sits in KEV.

Can a vector include Temporal or Threat metrics?

Yes. In 3.1, E, RL and RC are optional. In 4.0, Threat is just E; the spec's own example appends it: 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/E:A.

Why does NVD's score differ from the vendor's?

Different analysts, different information. NVD says its enrichment "reference[s] publicly available information to associate vector strings," and displays CVSS data from other sources too. The 4.0 User Guide also allows several Base scores for one vulnerability across versions or platforms. Compare vectors, not numbers.

Is CVSS 2 still used?

Not for new NVD records. NVD's retirement notice says that as of 13 July 2022 it no longer generates v2 vectors, ratings or scores; existing v2 data stays. Log4Shell's record still has a CVSS 2.0 tab. A v2 vector has no CVSS: prefix and uses Au, like AV:N/AC:M/Au:N/C:C/I:C/A:C.

Paste a vector you're triaging today into the CVSS Vector Parser. Check the version, Scope or the subsequent-system set, and every X before you trust the number.