How to Read a CVSS Vector String

An advisory says "CVSS 9.8, Critical." That is a conclusion. The evidence is the string next to it:

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

Each KEY:VALUE pair is one answer to one question about the vulnerability. Once you can read the string, you can check a score, spot a vendor who rated generously, and decide whether the number applies to your environment at all.

The CVSS calculator decodes any vector you paste in, so you can follow along with each example below.

The anatomy of a v3.1 vector

The first segment, CVSS:3.1, names the version. The scoring math differs between versions, so the same flaw can score differently under 3.1 and 4.0. That is expected, not a bug.

The eight base metrics follow, always in this order.

Metric	Question it answers	Values
AV Attack Vector	How close must the attacker be?	Network, Adjacent, Local, Physical
AC Attack Complexity	Does success depend on conditions the attacker can't control?	Low, High
PR Privileges Required	What access must they already have?	None, Low, High
UI User Interaction	Does a person other than the attacker have to do something?	None, Required
S Scope	Does the impact cross a security boundary?	Unchanged, Changed
C Confidentiality	How much data is exposed?	None, Low, High
I Integrity	How much can be altered?	None, Low, High
A Availability	How much can be disrupted?	None, Low, High

The first four describe how hard the attack is. Scope and the last three describe what the attacker gets.

Worked examples

Network, no privileges, no interaction, full impact.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H scores 9.8, Critical. Anyone who can reach the service can take it over with no login and no help from a victim. This is the shape of most "drop everything" remote code execution bugs.

Reflected cross-site scripting.

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N scores 6.1, Medium. It is remotely reachable, but a victim has to click (UI:R), and the impact lands in the victim's browser rather than on the vulnerable server. That crossing is what S:C records. The confidentiality and integrity impacts are low because the attacker is limited to what that one session can see and do.

Local privilege escalation.

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H scores 7.8, High. The attacker already needs an account on the machine (AV:L, PR:L), which is why this lands below the 9.8 despite the same total impact.

Compare the first and third: only two metrics differ (AV from N to L, PR from N to L), and the score drops two points. That is how to read a vector: find the metrics that moved.

What changed in v4.0

A v4.0 vector starts with CVSS:4.0/ and looks different:

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

That vector scores 9.3, Critical. The differences from v3.1:

• Scope is gone. Impact is split into the vulnerable system (VC, VI, VA) and subsequent systems (SC, SI, SA). The XSS example above would now express its browser-side impact through the subsequent-system metrics instead of flipping one switch.
• AT (Attack Requirements) is new. It captures deployment conditions the attacker can't control, such as a race window or a specific configuration, separately from how complex the exploit itself is (AC).
• UI has three values, not two: None, Passive, Active.
• Scores are named by what went into them. CVSS-B is base only. CVSS-BT adds a threat metric such as Exploit Maturity. A bare "CVSS 9.3" without that label doesn't say which one you are looking at.

The severity bands are the same in both versions: 0.1–3.9 Low, 4.0–6.9 Medium, 7.0–8.9 High, 9.0–10.0 Critical. v4.0 also uses 0.0 for None.

Three ways the number misleads

1. It is the vulnerability, not your exposure. A base score assumes nothing about where the flaw sits. A 9.8 on an internal host that nothing routes to and a 9.8 on your internet-facing edge are different risks. This is the central argument of continuous threat exposure management: severity is an input, exposure decides priority.

2. Two scorers, two vectors. A vendor advisory and NVD can publish different scores for the same CVE, because different analysts filled in the metrics. The vector tells you which of the answers differ. If one says PR:N and the other PR:L, you have found the actual disagreement and can judge it yourself.

3. Identical bands, different problems. Two 8.8s can be a network bug that needs a user click and a local bug that needs nothing but a shell. Sorting a queue by number alone throws that away. When everything is "High," the number stops carrying signal, which is the same failure alert fatigue describes in detection.

A habit that works

When a finding arrives with a score, read the vector before the number:

1. Is the attack vector one an attacker can use against how this system is deployed?
2. Do the privileges and interaction required match who can really reach it?
3. Do the impact values match what that component holds for you?

If you disagree with any answer, re-score with your values and keep both vectors in the ticket. The calculator will show you what each change does to the number.

For a score that goes into a published advisory, use the FIRST reference calculator. For the work around it, reading vectors in other people's advisories and re-scoring a queue, a calculator that runs locally is enough.