CVSS Score Explained: CVE, CVSS 4.0 and KEV in 2026

What a CVE Actually Identifies (and What It Doesn't)

A CVE is not a severity rating. It's an identifier. The CVE Program, run by MITRE as the CVE Numbering Authority, exists to give every publicly known vulnerability a unique ID so that vendors, researchers and tooling can all refer to the same flaw without ambiguity. Nothing about the number itself says whether the vulnerability is trivial or catastrophic.

That matters because practitioners routinely treat 'a CVE has been assigned' as if it were news about urgency. It isn't. Severity is a separate, deliberate scoring exercise that happens after the identifier exists — and that's where CVSS comes in.

CVSS v4.0: The Current Standard for Measuring Severity

CVSS — the Common Vulnerability Scoring System — is maintained by FIRST, and version 4.0 is the current official release, published on 1 November 2023. By mid‑2026 it has been the working standard for roughly two years, and an increasing share of new advisories, scanners and vulnerability feeds are adding support for this version alongside or in place of the older 3.1 methodology.

The clearest tell that you're looking at a v4.0 score is the vector string itself: it begins with the prefix CVSS:4.0, not CVSS:3.1. That prefix isn't cosmetic — it identifies the exact calculation rules used. The vector string is a slash-delimited sequence of metric-value shorthand; for instance, 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 breaks down into Attack Vector (AV: Network), Attack Complexity (AC: Low), Attack Requirements (AT: None), Privileges Required (PR: None), User Interaction (UI: None), and High impact to Vulnerable System Confidentiality, Integrity, and Availability (VC:H/VI:H/VA:H) with no downstream Subsequent System impact (SC:N/SI:N/SA:N).

Together, those metrics form the CVSS Base metric group, which evaluates the intrinsic technical characteristics of a vulnerability. Exploitability metrics assess how the flaw is reached and executed (Attack Vector, Attack Complexity, Privileges Required, User Interaction, and Attack Requirements), while Impact metrics evaluate the consequences across Confidentiality, Integrity, and Availability — assessed in v4.0 across both the vulnerable system and any subsequent systems, replacing v3.1's Scope metric.

The underlying formula converts these metrics into a score from 0.0 to 10.0, mapped to five official severity 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). These bands quantify technical severity rather than real-world threat — a distinction that shapes how teams must triage them alongside active exploit intelligence.

What Changed From v3.1 to v4.0 — and Why It Matters

The prefix change signals something bigger than a version bump: v3.1 and v4.0 vectors are not directly interchangeable, and tooling built to expect one prefix should not silently accept the other. Anyone auditing a vulnerability feed in 2026 should check which prefix dominates their data before comparing scores across systems.

The more consequential change is structural. FIRST has said that CVSS v4.0 reworked its Threat metric group so that it now incorporates measures of exploitability, drawing on threat intelligence sources such as CISA’s Known Exploited Vulnerabilities (KEV) catalogue. In practice, that's a direct answer to years of the same criticism this article opened with: a 9.8 that told you nothing about whether anyone was actually attacking the flaw. v4.0 at least gives the framework a formal channel for pulling that signal in, rather than leaving it entirely to separate systems.

Reading a 9.8: A Worked Decision, Not Just a Number

Take two hypothetical CVEs that both carry a CVSS 9.8 base score — the profile that sits at the top of the severity band. On the score alone, they look identical: drop everything, patch now. That's the trap.

Calculating the underlying vector — network-exploitable, low complexity, full impact — is done through FIRST's own scoring tools rather than by hand, and it always starts from that CVSS:4.0 prefix. But the operational question isn't how the number was calculated; it's what happens once it lands in a ticket. Walk both CVEs through the same four checks:

• •Base severity from the CVSS v4.0 vector — this reflects potential impact, not observed attacks.
• •A check against CISA's KEV catalogue — the authoritative public record of vulnerabilities confirmed as exploited in the wild.
• •A check against FIRST's EPSS model — a 30-day forward-looking exploitation probability, not a severity figure.
• •Exposure — is the affected asset internet-facing, or sitting on critical shared infrastructure.

KEV and EPSS: Two Different Signals, Not One

CISA maintains its Known Exploited Vulnerabilities catalogue as a verified register of security flaws actively targeted in real-world attacks — it's a curated, confirmed list, not a prediction. CISA publishes it as both CSV and JSON files, which means it can be pulled straight into ticketing systems or a SIEM without anyone manually retyping CVE IDs.

EPSS answers a different question entirely: FIRST's model estimates the probability that a vulnerability will be exploited in the next 30 days. It's a likelihood metric, forward-looking and probabilistic, where KEV is retrospective and binary — either a CVE is confirmed exploited, or it isn't yet on the list. Older, unsupported systems are frequently targeted, and many KEV‑listed vulnerabilities affect software or platforms that are no longer fully supported, which is one reason keeping end-of-support servers secure can't be separated from vulnerability triage.

How UK Organisations Turn Three Scores Into One Decision

NCSC's vulnerability management guidance gives UK teams a workflow, not a scoring threshold. It starts by grouping similar findings — its own example is aggregating multiple SSL-related issues into a single item — so that triage volume reflects real distinct problems rather than dozens of near-duplicate tickets.

From there, NCSC guidance splits work into three buckets: fix, acknowledge, or investigate. It's explicit that prioritisation should focus first on internet-facing services and applications, and on vulnerabilities that would cause the largest negative impact if exploited — including flaws in critical shared infrastructure. Crucially, NCSC also expects teams to record the date an issue will be fixed, which turns remediation timing into a tracked commitment rather than a vague intention buried in a scanner report.

None of this replaces CVSS, KEV or EPSS — it's the layer that decides which bucket a given score-plus-exploitation-signal actually belongs in. A proper IT risk assessment process is where that exposure and impact judgement gets formalised.

Where CVSS Falls Short — and What to Pair It With

CVSS is a base-severity framework. Conflating it with actual exploitation is the single most common misreading of the score, and it's exactly what v4.0's reworked Threat metric group is trying to narrow. KEV is a curated list of confirmed exploited flaws, not a probability. EPSS is a probability, not a severity rating. None of the three, taken alone, gives an organisation a complete risk picture.

What none of them can carry is local context: which systems are actually exposed to the internet, and which ones sit on business-critical infrastructure. That's where attack surface management earns its keep — it's what turns NCSC's 'internet-facing first' guidance from a principle on paper into an executable filter against a real asset inventory.

Best Practice: Automate the Inputs, Keep the Judgement Human

A practical shape for a 2026 triage process is straightforward once the pieces are separated out: pull CISA's KEV feed automatically in its CSV or JSON format, monitor EPSS movement on open vulnerabilities, and keep NCSC's fix/acknowledge/investigate labels attached to every ticket along with a recorded remediation date. None of that requires abandoning CVSS — it requires refusing to let a single number stand in for a decision.

In practice, many organisations still rely on single‑score SLAs — for example, "patch everything above 7.0 within 14 days" — which can leave lower‑scoring but actively exploited flaws under‑prioritised. Feeding CVSS, KEV and EPSS into the same cybersecurity services workflow, rather than treating them as competing dashboards, is what actually closes that gap.

Sources

Every figure in this article traces to the sources below.

• •FIRST — CVSS overview, EPSS definition and CVE/CVSS relationship
• •FIRST — CVSS v4.0 specification document and publication date
• •FIRST — CVSS v4.0 vector string format and user guide
• •FIRST — CVSS v4.0 Threat metric group changes
• •CISA — KEV catalogue authoritative status
• •CISA — KEV catalogue CSV/JSON feed formats
• •NCSC — vulnerability triage and prioritisation guidance