What Is a CVE?

Quick answer
CVE stands for Common Vulnerabilities and Exposures: a unique ID for each publicly disclosed security vulnerability.
An ID looks like CVE-2024-12345 — the year plus a sequence number.
CVEs are identifiers and descriptions, not a risk score; severity comes from scoring systems like CVSS.

What is a CVE?

CVE is a program, run by MITRE with community participation, that assigns a standardized identifier to each publicly known vulnerability. The identifier — CVE-YYYY-NNNNN — lets vendors, scanners, and researchers refer to the same flaw unambiguously. The US National Vulnerability Database (NVD) then enriches CVE records with severity scores and references.

How a CVE is assigned

When a vulnerability is discovered and reported, a CVE Numbering Authority (CNA) — often the vendor or a research organization — assigns it an ID and publishes a brief description. The description identifies the affected product and the nature of the flaw but deliberately stays high-level; the technical details, exploits, and fixes live in the references.

Why it matters

CVEs are the shared currency of vulnerability management. Scanners report findings by CVE, advisories reference them, and your SBOM becomes actionable when cross-referenced against CVE data. Knowing the CVE is the first step; the second is determining whether it affects you, which is its own skill.

CVE vs CWE

A CVE is a specific instance of a flaw (“CVE-2024-12345 in Product X”). A CWE (Common Weakness Enumeration) is a class of weakness (“CWE-89: SQL Injection”). One CWE can correspond to thousands of CVEs. Understanding both helps you see patterns rather than just individual bugs.

Where this bites vibecoders
AI assistants often reference CVEs confidently but loosely — citing the wrong ID, or treating “there’s a CVE” as “we’re doomed.” The practical skill is to look up the CVE, read the affected versions, and check whether you run one of them — not to react to the ID alone. Severity and applicability always need reading, never assuming.

Where AI coding assistants get this wrong

Citing CVEs that don’t match the dependency in question.
Treating every CVE as critical without checking CVSS or applicability.
Suggesting fixes by CVE number without verifying the affected version range.

Checklist

Treat a CVE as an identifier to investigate, not a verdict.
Look up the affected versions and compare against yours.
Check the CVSS score and vector for severity context.
Prefer the vendor advisory and NVD over secondhand summaries.
Track CVEs against your SBOM and dependencies.

FAQ

What is CVSS?

The Common Vulnerability Scoring System assigns a 0–10 severity score to a CVE, with a vector string explaining the factors (attack complexity, impact, etc.). It’s the standard way to prioritize vulnerabilities, though context still matters.

Where do I look up a CVE?

The NVD (nvd.nist.gov) and the MITRE CVE List (cve.org) are the authoritative sources. Vendor advisories often have the most accurate affected-version guidance. See How to Read a CVE.

Are all vulnerabilities assigned CVEs?

No. Many flaws — especially those found and fixed internally before public disclosure — never get a CVE. A CVE means the vulnerability is public and standardized, not that it’s the only (or worst) problem you have.