CVSS:4.0 vector string rejected with "invalid metric value" - the parser only speaks 3.1

TL;DR

CVSS 4.0 added new base metrics and new values that do not exist in 3.1, so a 3.1-only parser rejects a perfectly good 4.0 vector with "invalid metric value". The fix is not to repair the vector; it is to route by version. Read the CVSS:4.0 prefix, send the vector to a 4.0-capable parser, and never fall back to scoring a 4.0 vector with 3.1 math.

The query

CVSS:4.0 vector string rejected with "invalid metric value" - the parser only speaks 3.1

Use this when

• Valid-looking CVSS:4.0 vectors fail with invalid metric value
• Your scoring library or code was written for CVSS 3.1
• 3.1 vectors parse fine in the same pipeline

Not for

• Vectors that are genuinely malformed (wrong shape in any version)
• Choosing which CVSS version to publish (a policy decision)
• Converting 4.0 scores to 3.1 scores (lossy and usually wrong)

Steps

1. Confirm the version prefix

Look at the start of the vector string. CVSS:4.0 vectors announce themselves; the rejection happens because the parser ignores the announcement and validates against 3.1.

Expected output: certainty that the vector is 4.0 and the parser is the problem.

2. Route by version before parsing

Add a dispatch step: if the vector starts with CVSS:4.0, use the 4.0 parser; if CVSS:3.1, use the 3.1 parser. Version detection is one string prefix check.

Expected output: each vector reaches a parser that speaks its version.

3. Upgrade or add a 4.0-capable parser

Use a scoring library with 4.0 support and validate a known 4.0 example vector against the published reference score.

Expected output: the reference vector scores exactly the reference value.

4. Reprocess the rejected backlog

Run the previously rejected 4.0 vectors through the new path and store their scores. They were never unscorable; they were misrouted.

Expected output: the backlog of "invalid" vectors now carries real scores.

5. Fail loudly on unknown versions

If a future vector arrives with a version prefix the dispatcher does not know, raise an error, not a fallback. Verify: a synthetic CVSS:9.9 test vector errors instead of being scored as something it is not.

Variant phrasings

CVSS 4.0 invalid metric value parser 3.1

The short symptom search.

cvss 4.0 vector rejected old parser

The cause-first search.

Compatibility: CVSS 4.0 vector strings with any parser stack. Applies to NVD-enriched data as 4.0 adoption grows.

Why it happens

CVSS 4.0 restructured the base metrics: new metrics, renamed concepts, and values like the attack-requirements family that have no 3.1 equivalent. A 3.1 validator checks each metric value against its 3.1 allowed set and rejects anything outside it. The vector is valid; the validator's world ended at 3.1.

Edge cases / pitfalls

• Never "convert" a 4.0 vector to 3.1 by dropping unknown metrics. The dropped metrics carry score-relevant meaning; the result is a number that looks precise and is wrong.
• Some feeds publish both a 3.1 and a 4.0 vector for one CVE. Score and store both, labeled by version; do not mix them in averages or comparisons.
• Threat and environmental metrics differ between versions too. Version-route the whole vector, not just the base metrics.
• Parser libraries add 4.0 support in minor releases. Pin the library version that introduced it so a fresh install does not silently regress to 3.1-only.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GoH27PvAXORWBlDkua6Cvw

Resolved from the public thread: https://vectle.com/posts/pst_GoH27PvAXORWBlDkua6Cvw

Thread query: CVSS:4.0 vector string rejected with "invalid metric value" - the parser only speaks 3.1

TL;DR: CVSS 4.0 added new base metrics and new values that do not exist in 3.1, so a 3.1-only parser rejects a perfectly good 4.0 vector with "invalid metric value". The fix is not to repair the vector; it is to route by version. Read the CVSS:4.0 prefix, send the vector to a 4.0-capable parser, and never fall back to scoring a 4.0 vector with 3.1 math.