CVSS 4.0 Score Calculator vs CVSS 3.1: What Changed in Vulnerability Scoring

CVSS 4.0 removes Scope, adds Attack Requirements and separate impacts on subsequent systems, replaces Temporal with a single Threat metric, and adds Supplemental metrics that do not change the score.

The new names make clear which metrics went into a number. A vendor advisory usually publishes CVSS-B. Your team should aim to report CVSS-BTE, which adds threat and environment data.

CVSS v4 has 11 base metrics: five for exploitability (AV, AC, AT, PR, UI) and six for impact (VC, VI, VA, SC, SI, SA).

Attack Requirements covers conditions the attacker does not control, such as a race condition or a specific deployment setting. In 3.1 those details were squeezed into Attack Complexity.

The split between vulnerable and subsequent systems replaces Scope. A browser bug that compromises the page but not the operating system now scores high on VC and low on SC, instead of flipping one Scope switch.

CVSS 4.0 groups the metrics into six equivalence sets (EQ1–EQ6), looks up a score for the resulting MacroVector in a table set by FIRST experts, and then adjusts it within that group.

CVSS 3.1 used a formula. You can still compute it by hand, which makes the difference between the versions easy to see.

v3.1: ISS = 1 − (1 − C)(1 − I)(1 − A) Impact = 6.42 × ISS (scope unchanged) Exploitability = 8.22 × AV × AC × PR × UI Base = Roundup(min(Impact + Exploitability, 10))

CVSS 4.0 does not have an equivalent closed formula. The 270 possible MacroVectors each carry a score, and the final value moves down within its MacroVector based on how far the exact vector sits from the most severe vector in that group.

1. Map the full vector to six equivalence-class values (EQ1 to EQ6).
2. Combine them into a MacroVector such as 000000 and look up its score.
3. Measure the severity distance from the highest vector in that MacroVector.
4. Subtract the proportional distance and round to one decimal place.

Because of the lookup table, hand calculation is impractical for CVSS v4. Use a calculator that implements the FIRST reference tables, such as the CVSS 4.0 score calculator.

An unauthenticated network RCE scores 9.8 in CVSS 3.1 and 9.3 in CVSS 4.0. A flaw that also fully compromises other systems scores 10.0 in both.

The 4.0 vectors start with the CVSS:4.0/ prefix in practice; it is omitted above for width. Note how 4.0 keeps 10.0 for cases with real downstream damage, which leaves more room between "bad" and "worst case".

Threat (E) lowers the score when no exploitation is known. Environmental metrics adjust it for how important the affected asset is to you.

Exploit Maturity has three values: Attacked (E:A), POC (E:P) and Unreported (E:U). If you leave it as Not Defined, CVSS 4.0 assumes Attacked, the worst case. That default is deliberate, so do not lower a score without evidence.

Environmental metrics include Confidentiality, Integrity and Availability Requirements (CR, IR, AR) and modified versions of every base metric. A bug on an isolated lab host can drop a full severity band once MAV and CR reflect reality.

Supplemental metrics such as Safety, Automatable and Recovery never change the number. Use them in tickets to explain priority to engineers and managers.

Both CVSS 3.1 and 4.0 use the same bands: None 0.0, Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9 and Critical 9.0–10.0.

CVSS measures severity, not risk. Combine it with known-exploited data, such as the CISA KEV catalog, and with asset criticality before you set patch deadlines.

Extract the CVE IDs, record the vendor vector, add threat and environmental metrics, and store the result next to your patch policy.

1. Pull CVE IDs, hashes and URLs out of the advisory with the IOC Extractor.
2. Enter the vendor vector in the CVSS calculator and keep both 3.1 and 4.0 strings during the transition.
3. Set E from threat intel and CR/IR/AR from your asset inventory, then record the CVSS-BTE score.
4. Store the thresholds as code. Convert your SLA policy between JSON and YAML with the policy converter.

cvss_version: "4.0"
sla_days:
  critical: 7    # 9.0 – 10.0
  high: 30       # 7.0 – 8.9
  medium: 90     # 4.0 – 6.9
  low: 180       # 0.1 – 3.9
override:
  known_exploited: 3

This keeps the score, the evidence behind it and the deadline in one place. Auditors and engineers can then follow how each decision was made.

Record both during the transition. Many advisories still publish only 3.1 vectors, while new CNA records increasingly include 4.0, so a single-version process will miss data.

Keep the version prefix with every vector, such as CVSS:3.1/ or CVSS:4.0/. A bare score of 9.8 or 9.3 means little unless you know which model produced it.

Do not convert one version into the other by hand. The metrics do not map one to one, because Scope has no direct 4.0 equivalent and Attack Requirements has no 3.1 equivalent. Score each version from the original vulnerability details instead.

Set your patch SLAs by severity band rather than exact decimals. The bands are identical in both versions, so the policy stays stable while the scores underneath change.