CVE vs CVSS: what's the difference?

Open any vendor security advisory and you'll usually see two things bolted together: a code like CVE-2024-12345 and a number like 9.8 CRITICAL. It's easy to treat them as one piece of information, but they come from two different organizations, answer two different questions, and get confused constantly. CVE (Common Vulnerabilities and Exposures) is a naming system — it identifies what a specific vulnerability is, so everyone can talk about the same flaw without ambiguity. CVSS (Common Vulnerability Scoring System) is a severity scale — it measures how bad that vulnerability is on a scale from 0 to 10. One names the problem. The other rates it. This article explains both in detail, and decodes a real CVSS vector string piece by piece so the score stops being a black box.

What CVE actually is

CVE is a catalog of publicly known vulnerabilities, maintained by MITRE Corporation under funding from the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Its entire job is disambiguation: before CVE existed, different vendors, scanners, and researchers routinely used their own internal names for the same underlying flaw, making it hard to tell whether two advisories were describing one bug or two. CVE fixes that by assigning every qualifying vulnerability a single, permanent identifier in the format:

CVE-2024-12345
     ^^^^  ^^^^^
     year  sequence number

The year reflects when the ID was assigned, not necessarily when the vulnerability was discovered, disclosed, or fixed — an ID reserved in December can be publicly disclosed the following spring still carrying the earlier year. MITRE doesn't personally vet every submission; it accredits organizations called CVE Numbering Authorities (CNAs) — major vendors, security research firms, bug-bounty platforms, and coordination centers — to assign IDs for vulnerabilities within their own scope. A typical CVE record contains:

Notice what's missing: a severity score. A raw CVE record just says a flaw exists and describes it — it does not, by itself, tell you how dangerous that flaw is. That job belongs entirely to CVSS.

What CVSS actually is

CVSS is maintained by FIRST.org (the Forum of Incident Response and Security Teams), an independent nonprofit — a different organization from MITRE, run for a different purpose. Where CVE answers "what is this flaw," CVSS answers "how severe is it," expressed as a single number from 0.0 to 10.0. That number isn't assigned by gut feeling; it's calculated from a set of standardized metrics describing how a vulnerability can be exploited and what happens if it is, each one encoded into a compact vector string that anyone can read back to see exactly how the score was built.

CVSS has gone through several major revisions — version 2 in 2007, version 3.0 and its refinement 3.1 in 2015 and 2019, and version 4.0 released by FIRST.org in 2023. CVSS 3.1 remains the version you'll encounter most often in vendor advisories and vulnerability databases today, so it's the version worth understanding in depth first.

The CVSS 3.1 Base Score metrics

The Base Score is built from eight metrics, split into two groups: Exploitability metrics describing how an attacker reaches and exploits the flaw, and Impact metrics describing what happens to the system once they do.

Each metric's chosen value feeds into a defined formula published in the CVSS specification, which outputs the final 0.0–10.0 Base Score. You never have to run that formula by hand — every scanner, advisory, and the NVD (NIST's National Vulnerability Database) calculator does it for you — but understanding what each letter means turns an opaque number into a legible technical summary.

Decoding a real vector string

A CVSS vector string packs all eight metrics into one line, in a fixed order, prefixed with the CVSS version. Here's a representative example for the kind of flaw that regularly earns a Critical rating — an unauthenticated, remotely exploitable vulnerability with full impact:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Read left to right, piece by piece:

• AV:N — Attack Vector: Network. Exploitable remotely over a network connection, no physical or local access needed.
• AC:L — Attack Complexity: Low. No special conditions or timing are required; a reliable exploit works consistently.
• PR:N — Privileges Required: None. The attacker needs no prior authentication or account access at all.
• UI:N — User Interaction: None. No victim has to click, open, or do anything for the exploit to succeed.
• S:U — Scope: Unchanged. The impact stays within the security authority of the vulnerable component itself.
• C:H — Confidentiality Impact: High. A successful attacker can read data they shouldn't be able to access.
• I:H — Integrity Impact: High. A successful attacker can modify data or system state they shouldn't be able to touch.
• A:H — Availability Impact: High. A successful attacker can disrupt or take down the affected system entirely.

Every metric in that string points toward maximum severity — reachable by anyone on the network, no login needed, no user interaction, no special conditions, and complete compromise of confidentiality, integrity, and availability. Run through the CVSS 3.1 formula, a vector like this lands at 9.8, placing it in the Critical band. Change just one metric — say PR:N to PR:H, requiring an attacker to already hold high privileges — and the score drops substantially, because the population of people who could actually exploit it shrinks dramatically. That's the entire point of the vector string: the score is fully explained by its inputs, not asserted from nowhere.

Reading the severity scale

The CVSS specification also defines a qualitative scale so scores can be discussed without memorizing exact numbers:

Beyond the Base Score, CVSS 3.1 also defines optional Temporal metrics (which adjust for things like whether working exploit code is publicly available or an official patch exists) and Environmental metrics (which let an organization re-weight the score based on how critical the affected asset actually is in their own environment). In practice, the Base Score is what gets published in advisories and databases; Temporal and Environmental scoring is applied locally by the organizations actually prioritizing remediation.

CVSS 4.0: what changed

FIRST.org released CVSS 4.0 in 2023 to address several long-standing criticisms of version 3.1. The core 0-to-10 scoring philosophy carries over, but the metric set was refined: a new Attack Requirements (AT) metric separates out conditions that exist independent of privileges or user interaction, the confusing Scope metric is replaced with clearer Vulnerable System and Subsequent System impact metrics that describe blast radius more precisely, and scores are now explicitly labeled by which metric groups were used to calculate them (CVSS-B for Base only, CVSS-BE for Base plus Environmental, and so on), making it obvious at a glance how complete a given score actually is. Adoption has been gradual — CVSS 3.1 remains the version you'll see in the large majority of published advisories today, but 4.0 scores are increasingly common in newer disclosures.

Looking up CVE and CVSS data yourself

Both catalogs are free and public, and checking them directly is usually faster and more reliable than trusting a secondhand summary. CVE.org is the authoritative source for the CVE record itself — search by ID or keyword to see the canonical description and which CNA assigned it. NIST's National Vulnerability Database (NVD) is where most people actually go for the fuller picture, because it layers CVSS scores, CPE-matched affected products, and CWE weakness classifications on top of the base CVE record.

NVD also exposes a public JSON API, so a CVE's full record — including its exact CVSS vector string — can be pulled straight from the command line rather than read off a web page:

# Look up a well-known CVE and extract its published CVSS 3.1 vector
$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228" \
    | jq -r '.vulnerabilities[0].cve.metrics.cvssMetricV31[0].cvssData.vectorString'
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

That's the real, published NVD vector for CVE-2021-44228 — Log4Shell, the critical remote-code-execution flaw in the widely used Apache Log4j logging library, disclosed in December 2021. It matches the worked example above almost metric for metric, with one instructive difference: S:C, Scope Changed, instead of S:U. Because Log4j is a logging component embedded inside countless other applications, successfully exploiting it could let an attacker execute code in the context of the entire host application — an impact that reaches beyond the vulnerable component's own security authority, which is exactly the condition the Scope metric exists to capture. The overall base score still lands at 10.0, the maximum possible, and Critical.

How CVE and CVSS work together in practice

The relationship is complementary, not competing, and understanding that resolves most of the confusion: CVE gives you a stable name to reference across vendor advisories, scanner output, patch notes, and news coverage, so everyone is unambiguously discussing the same flaw. CVSS gives that named flaw a comparable severity score, so a team facing dozens or hundreds of open CVEs has an objective, reproducible starting point for triage instead of guessing which ones matter most. The NVD is where these two systems most visibly meet — NIST's National Vulnerability Database ingests CVE records from MITRE and enriches them with CVSS scores, CPE affected-product data, and other context, making it the most commonly cited source for "the CVSS score of a CVE" even though CVE and CVSS themselves come from entirely separate organizations.

A CVSS Base score alone is not the whole prioritization story, though. It measures theoretical severity assuming exploitation happens, but says nothing about whether anyone is actually exploiting a given flaw right now. That's why mature vulnerability management pairs CVSS with real-world signals — most notably CISA's Known Exploited Vulnerabilities (KEV) catalog, a public list of CVEs confirmed to be under active exploitation, alongside the exposure of the specific affected asset. A Critical-rated flaw sitting on an air-gapped internal system can reasonably wait behind a Medium-rated flaw on an internet-facing server that KEV confirms is being actively attacked.

The takeaway

CVE and CVSS solve different problems for different reasons. CVE, run by MITRE, gives every publicly known vulnerability a single, unambiguous name in the format CVE-YYYY-NNNNN. CVSS, run by FIRST.org, scores how severe that named vulnerability is on a transparent 0-to-10 scale built from a decodable vector string covering how it's exploited and what it damages. Neither replaces the other, and neither should be read alone: a CVE ID tells you what you're dealing with, a CVSS score tells you roughly how bad it is in the abstract, and real-world exploitation data tells you whether it's actually being used against systems like yours right now. Prioritization happens at the intersection of all three.

Frequently asked questions