A CVSS vector string starts with the label CVSS and a version, then lists metrics as abbreviated name, colon, value, separated by slashes. Split on the slash, read the version from the first part, require every base metric, and treat missing optional metrics as Not Defined. Metric order rules differ between 3.1 and 4.0.
What the string looks like
The FIRST specification gives this 3.1 example: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N. The first segment is the version label. Every other segment is a metric abbreviation and a value. AV:N reads as Attack Vector: Network.
A 4.0 string has the same outer shape, with a different metric set, such as 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. That example appears in the OSV schema documentation.
The metrics you must see
| Group | 3.1 base metrics | 4.0 base metrics |
|---|---|---|
| Exploitability | AV, AC, PR, UI | AV, AC, AT, PR, UI |
| Scope or system | S | none |
| Impact | C, I, A | VC, VI, VA, SC, SI, SA |
All base metrics are mandatory in both versions. Temporal and environmental metrics in 3.1, and threat, environmental and supplemental metrics in 4.0, are optional. The specification says omitted ones are treated as Not Defined, written X.
Rules that differ by version
For 3.1, the specification says a vector should list metrics in the order of its table, but other orders are valid. A program reading 3.1 vectors must accept any order.
For 4.0, the rule is stricter. The specification says metrics must appear in the table order and every other ordering is invalid. It also says the abbreviations and values are case sensitive.
Both versions say a metric must not appear twice.
A parsing routine
- Split the string on the slash character.
- Check that the first part starts with CVSS followed by a colon and a version. Choose the rule set from the version.
- Split each remaining part once on the colon into name and value.
- Reject duplicates.
- Check that all base metrics are present and each value is in that metric's allowed set.
- For 4.0, also check the order. For 3.1, accept any order.
- Fill omitted optional metrics with X.
Do not compute a score by guesswork. The specifications define the equations, so use a maintained library or implement the published formulas and test against the official calculator.
Where vectors show up in data feeds
Vulnerability records often carry the vector rather than a number. The OSV schema has a severity array where each item has a type and a score. The types CVSS_V2, CVSS_V3 and CVSS_V4 hold vector strings in that score field, not a numeric rating, and the schema distinguishes them by version range. Route each by type, and run the matching parser.
Another trap is mixing sources. A record may carry a rating from the database, one from the CVE numbering authority and one from NVD. Keep the source with every score, so you can explain a disagreement later.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how severity is one input to the decision and exploitability is another.
Where this fits
A parsed vector tells you how bad a flaw could be in general. It does not tell you whether your code is exposed. Safeguard offers reachability analysis to answer that, and the free scan is a quick way to see it.
Quick check
Do 3.1 and 4.0 vectors share the same metrics?
No. Version 4.0 adds Attack Requirements and splits impact into vulnerable system and subsequent system metrics, and it drops Scope.
Can I accept metrics in any order?
For 3.1, yes. For 4.0, no. The 4.0 specification says only the table order is valid.
Sources
- CVSS v3.1 specification, vector string section
- CVSS v4.0 specification, vector string section
- OSV schema specification
Last reviewed: 19 October 2026.
