CVSS v4: What Changed From v3.1 and How to Use It

CVSS v4 is not a new patch priority number. The problem is not learning another 0 to 10 scale. It is deciding who owns the threat and environment facts that turn shared severity into a local response.

Version 4 keeps the familiar range, but it changes the vocabulary, scoring method, and division of labor. A supplier can describe the vulnerability. Only the operator knows whether a firewall, service route, data classification, or recovery requirement changes the local severity.

If your migration merely swaps a v3.1 Base score for a v4 Base score, you will get new numbers and the same bad queue.

What is CVSS v4?

CVSS v4 is version 4.0 of the Common Vulnerability Scoring System maintained by FIRST. The standard represents technical severity through a vector string and a score from 0.0 to 10.0. The official CVSS v4 specification was first published on November 1, 2023.

The vector matters more than the decimal. The score compresses a set of attack and impact choices. FIRST requires publishers of CVSS data to provide both the score and vector so consumers can see how the result was derived.

Use that shared description inside a broader vulnerability prioritization process. CVSS says how bad the technical outcome can be under stated conditions. It does not tell you whether exploitation is likely, whether the affected product is deployed, or which change should happen first.

What changed from CVSS v3.1 to CVSS v4?

The largest change is not one metric. Version 4 makes the vulnerable system and a subsequent affected system explicit. Version 3.1 used Scope to describe impact crossing an authority boundary. That proved hard to score consistently. Version 4 replaces Scope with separate confidentiality, integrity, and availability impacts for both systems.

Attack Complexity was narrowed. A new Attack Requirements metric captures deployment conditions that must be present for exploitation, such as a race condition or a particular network state. This helps distinguish attacker difficulty from conditions outside the attacker's control.

User Interaction now uses None, Passive, or Active. Passive covers cases where normal user behavior helps exploitation without a deliberate step to bypass protection. Active means the user must perform a specific action, such as opening a file or dismissing a warning.

The old Temporal group is now Threat, with Exploit Maturity as its scored metric. Remediation Level and Report Confidence moved out of the scored groups. New Supplemental metrics describe properties such as Safety, Automatable, Recovery, Value Density, provider Urgency, and response effort. Supplemental values add useful language but do not change the CVSS score.

How do the four CVSS v4 metric groups work?

Base metrics describe attack conditions and technical impact intrinsic to the vulnerability. Every valid v4 vector includes all 11 Base metrics: Attack Vector, Attack Complexity, Attack Requirements, Privileges Required, User Interaction, and six impact values covering the vulnerable and subsequent systems.

Threat captures current exploit maturity. Environmental metrics let a consumer modify attack and impact values for the deployed system and set security requirements for confidentiality, integrity, and availability. Supplemental metrics convey facts that may shape response without changing the number.

Communicate which groups are present. CVSS-B means Base. CVSS-BT includes Base and Threat. CVSS-BE includes Base and Environmental. CVSS-BTE includes all three scored groups. A naked “8.7” hides whether current threat and local controls were assessed.

FIRST published a new CVSS v4 Consumer Implementation Guide on January 6, 2026. It makes the ownership split plain: producers assign a Base assessment, while consumers enrich it with threat intelligence and their deployment environment. That guide is the recent development many early v4 summaries do not include.

How do you read a CVSS v4 vector?

A v4 vector begins with the version marker, then lists metric and value pairs separated by slashes. This official example describes a network reachable issue with low complexity, no special attack requirement, no privilege or user interaction, and high impact to the vulnerable system:

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

FIRST's January 2026 guide gives that vector a CVSS-B score of 9.3. If local evidence changes Modified Attack Vector from Network to Adjacent because a firewall limits the route, the guide shows 8.7. Adding an effective intrusion prevention condition that changes Modified Attack Complexity to High produces 7.7.

That is simple math with operational consequences. A single 9.3 Base record can represent many local scores. If 400 affected assets sit behind four different control patterns, one Base score cannot support 400 identical tickets. Group assets by the evidence that changes the vector and by the fix they can share.

Do not edit a supplier's Base vector to describe your environment. Retain the source vector. Add explicit Environmental values in your own assessment, along with the observation, reviewer, and time that support each modification.

Why can the same decimal hide different CVSS v4 facts?

The January 2026 implementation guide notes that vector strings have thousands of possible permutations, while the 0.0 to 10.0 scale has only 101 steps in tenths. Many different vectors must land on the same decimal.

Version 4 also changed the scoring method. It groups comparable vectors into MacroVectors based on expert ranking, assigns values through lookup tables, then interpolates within those groups. You cannot compare a v3.1 score and v4 score as if one were a currency conversion.

Store the version, vector, provider, assessment type, score, and collection time as separate fields. Never overwrite v3.1 with v4 in place. Keep both during migration so reports, service agreements, and historical decisions remain reproducible.

How should a data pipeline handle CVSS v4?

NVD's CVE API supports filters for v4 severity and partial v4 vectors. The following request follows the official NVD vulnerability API documentation and returns five records with a High v4 severity:

curl -sG 'https://services.nvd.nist.gov/rest/json/cves/2.0' \
  --data-urlencode 'cvssV4Severity=HIGH' \
  --data-urlencode 'resultsPerPage=5' \
  | jq '{totalResults, cves: [.vulnerabilities[].cve.id]}'

Treat CVSS v4 fields as optional. A missing v4 assessment is not zero severity. Preserve the available v3.1 record, supplier advisory, and enrichment status. Mark which source supplied each assessment because a CNA and NVD may publish different vectors.

NIST announced on April 15, 2026 that CVE submissions had increased 263 percent from 2020 through 2025 and that submissions in the first quarter of 2026 were nearly one third higher than the same period a year earlier. Its NVD operations update also moved older backlogged records to Not Scheduled under new enrichment criteria.

That makes source and status handling part of the migration. A pipeline that turns missing enrichment into a low score will create false calm as volume rises.

What should a CVSS v4 migration include?

1. Inventory every producer, API field, report, ticket rule, and service agreement that consumes CVSS.
2. Store v3.1 and v4 assessments side by side with full vectors and source identifiers.
3. Assign owners for Threat and Environmental evidence instead of leaving every value undefined.
4. Run both versions against 90 days of findings and measure queue volume, category changes, and overrides.
5. Update reporting labels to show CVSS-B, CVSS-BT, CVSS-BE, or CVSS-BTE.
6. Change remediation policy only after owners approve the workload and exception behavior.

Compare the new data contract with the older guide to reading CVSS scores and vectors. Then use EPSS probability for forecast threat and local evidence for affected state. Version 4 improves the severity language. It does not collapse those other questions.

How should CVSS v3.1 and v4 coexist in policy?

Write policy against named inputs, not whichever field a scanner labels `score`. A rule should say “CVSS-B v4 Critical from the primary source” or “CVSS v3.1 Base at least 9.0 when no v4 assessment exists.” Version, assessment type, and source belong in the condition.

Decide how conflicting assessments are displayed before they appear. Do not automatically keep the highest score and discard the rest. A CNA may have product knowledge that NVD lacks. NVD may add a secondary analysis. Show both vectors, name the source selected by policy, and record why.

Service agreements need the same precision. If a contract says every Critical vulnerability must close in 15 days, specify the CVSS version and metric group. Otherwise the due date can change when a data provider adds a Threat or Environmental assessment, even though the vulnerable state did not change.

Reports should separate coverage from severity. One chart can show the percentage of active findings with a v4 Base assessment. Another can show urgent actions by policy rule. Combining them makes missing v4 data look like lower risk.

Historical trends require frozen facts. Keep the vector and score that supported the decision at that time. Also retain later assessments as new records. Recomputing last quarter with today's vector may help analysis, but it cannot replace the evidence used for the original due date.

Run exception tests before the cut. What happens when only v3.1 exists? What happens when v4 Base is High but v3.1 Base was Critical? What happens when the supplier adds a v4 vector after a ticket closes? Each answer needs an explicit route, not a silent database update.

Should CVSS v4 determine patch priority?

No. FIRST's own user guide says a Base score represents intrinsic characteristics and excludes threat and the consumer's environment. Even CVSS-BTE remains a severity assessment, not a full work decision.

Patch priority also needs known exploitation, predicted exploitation, exposure, business consequence, compensating controls, owner capacity, and change risk. The vulnerability risk scoring guide shows how to keep those inputs visible instead of hiding them inside one vendor number.

Most ranking articles compare metric names and show a calculator. Few explain a dual version data contract, assessment ownership, missing enrichment behavior, or a 90 day shadow run. Those are the parts that decide whether migration improves work or merely changes dashboard colors.

Frequently asked questions

Is CVSS v3.1 obsolete?

No immediate switch makes old records invalid. Keep v3.1 where it is the available assessment, add v4 when a trusted source supplies it, and label the version in every report and rule.

Does a CVSS v4 Base score include exploit probability?

No. Base metrics describe technical severity. Threat metrics describe exploit maturity. EPSS supplies a separate forecast probability based on observed patterns.

Do Supplemental metrics change the CVSS v4 score?

No. They describe facts such as Safety, Automatable, Recovery, and provider Urgency that may influence response, but the CVSS number does not change.

Can a local team change a supplier's CVSS vector?

Preserve the supplier's Base vector. Create a separate consumer assessment with Threat and Environmental values, evidence, source time, and reviewer.

Executive takeaway

Do not approve a CVSS v4 migration that only changes a numeric field. Require the full vector, source, version, and assessment type. Give Threat and Environmental metrics named owners. Run v3.1 and v4 beside each other for 90 days, then inspect the work that moves. Use deep endpoint context with AI driven analysis where it helps verify local conditions, but keep every changed metric tied to human readable evidence.