What Is a CVE? CVE IDs, Records and Lookups Explained

A CVE (Common Vulnerabilities and Exposures) is a unique, public identifier for one specific security vulnerability in one specific product, such as CVE-2021-44228 for the Log4Shell flaw in Apache Log4j. So the short answer to "what is a CVE" is: it is the shared name that vendors, vulnerability scanners, security advisories and patch notes all use, so that everyone is talking about the same bug.

That shared name matters because roughly 40,000 CVEs were published in 2024 alone. Without a common identifier, matching a vendor advisory to a scanner finding and then to the right patch would be guesswork. This guide explains how CVE IDs are built, who assigns them, what happens to a CVE record over its life, and how your team should actually use CVE data.

What is a CVE ID and how is it formatted?

Every CVE ID has three parts: the prefix CVE, a year and a sequence number, for example CVE-2024-3094. Three details are often misunderstood:

• The year is the year the ID was reserved or assigned, not necessarily the year the flaw was discovered or made public. An ID reserved in December can be published the following year.
• The sequence number has at least four digits and can be longer, so CVE-2024-12345 is perfectly valid.
• The number says nothing about severity. Severity comes from CVSS and threat data, never from the ID itself.

What a CVE record contains

• The ID and the record state (reserved, published or rejected)
• A short description of the flaw and its impact
• The affected vendor, product and versions
• References such as the vendor advisory, the fix or the researcher's write-up
• Often a weakness type (CWE) and a CVSS score supplied by the assigning organization

What a CVE is not

A CVE is not a severity score, not a fix, and not proof that anyone is exploiting the flaw. Not every security problem gets one either: insecure settings on your own servers or bugs in an internal application used only by your company usually have no CVE. That is why vulnerability scanning should run alongside configuration audits and system hardening.

Who runs the CVE program: MITRE, CNAs and CISA

The CVE Program is an international, community-driven effort operated by MITRE and sponsored by the US Cybersecurity and Infrastructure Security Agency (CISA). Assigning IDs is distributed:

• CNAs (CVE Numbering Authorities) are organizations authorized to assign CVE IDs and publish records within a defined scope. They include large software vendors such as Microsoft, Red Hat and Google, open-source projects, national CERTs and some bug bounty platforms.
• Root CNAs and the CNA of Last Resort cover cases where the affected vendor is not itself a CNA, so a vulnerability does not go without an ID.
• The CVE Board sets the program's policies and rules.

Note that the National Vulnerability Database (NVD) is not part of the CVE Program. NVD is run by NIST, and its job is to analyze and enrich the records the CVE Program publishes.

The lifecycle of a CVE record

Every CVE follows a predictable path:

1. Discovery: a security researcher, the vendor's own team or, sometimes, attackers find the flaw.
2. Reserve ID: the reporter contacts the right CNA and an ID is reserved. During coordinated disclosure the details stay private so the vendor has time to build a fix.
3. Publish: once a fix or advisory is ready, the CNA publishes the record with a description, affected versions and references, and it becomes searchable on cve.org.
4. Enrichment: NVD and other data publishers add a CVSS score, the CWE weakness type and CPE product identifiers.
5. Patch: the vendor releases a fixed version or a workaround, and Linux distributions backport the fix into their own packages.
6. Scan and verify: organizations find affected assets, apply the fix and rescan to confirm it worked.

If a report turns out to be a duplicate or not a real vulnerability, the record is marked rejected. Published records can also be updated later.

NVD enrichment: CVE vs CWE vs CPE

NVD adds analysis to bare CVE records so tools can use the data automatically. Enrichment does not always keep pace with publication, and there have been periods with a large backlog of unanalyzed CVEs. For important vulnerabilities, also check the vendor advisory and the data the CNA provided.

Term	What it identifies	Example	Maintained by
CVE	One specific vulnerability in one product	CVE-2021-44228	CVE Program (MITRE and CNAs)
CWE	A type or class of software weakness	CWE-89 (SQL injection)	MITRE
CPE	A standardized product and version name	cpe:2.3:a:apache:http_server:2.4.49 (shortened)	NIST (CPE Dictionary in NVD)
CVSS	Technical severity on a 0–10 scale	9.0–10.0 = Critical	FIRST

CWE vs CVE

CWE describes the root cause; CVE describes a real instance of it. "SQL injection" is a CWE, and thousands of different CVEs in different products trace back to that one weakness. Looking at which CWEs keep appearing in your own findings helps developers fix causes instead of symptoms.

CPE: matching CVEs to your software

CPE turns a product name into a machine-readable string so a scanner can decide whether "this Apache version on this server" is in the list of affected versions. A common trap: distributions such as Red Hat and Debian backport security fixes without changing the upstream version number. A scanner that only reads service banners may flag a patched server as vulnerable, while an authenticated scan that inspects installed packages gives far more accurate results. Our vulnerability scanner guide covers this in detail.

How to look up a CVE

Use these sources, roughly in order of precision:

• The vendor's security advisory: the most accurate source for affected versions, fixes and workarounds.
• cve.org: the official record and its references.
• NVD: CVSS scores, CWE and the list of affected CPEs.
• Your Linux distribution's security tracker: the fix status in that distribution's packages.

For automation, NVD offers a public API, and on servers you can check package changelogs:

# Fetch a single CVE from the NVD CVE API 2.0 (JSON)
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228"

# RHEL family: list CVE references in the installed package's changelog
rpm -q --changelog openssl | grep -i "CVE-"

# Debian/Ubuntu: same check using the package changelog
apt changelog openssl | grep -i "CVE-"

Zero-day vs n-day vulnerabilities

• Zero-day: a flaw that is known to attackers or exploited before the vendor has released a fix. It may have no CVE yet, or only a reserved one. The main defenses are hardening, reducing the attack surface, network segmentation and monitoring.
• N-day: a flaw that has been publicly disclosed and usually has a fix available. Attackers routinely use n-days because many organizations patch slowly, and the gap between public disclosure and exploitation can be short.

For most organizations, handling n-days quickly and consistently is the bulk of day-to-day vulnerability work.

How organizations should use CVE feeds

A CVE feed only becomes valuable when it is connected to your assets and processes:

1. Keep an asset inventory with exact software names and versions; without it, CVE matching is impossible.
2. Match new CVEs against that inventory automatically and send only relevant ones to the team.
3. Prioritize with threat data, not CVSS alone; see CVSS vs EPSS vs KEV for a practical model.
4. Define remediation SLAs per priority and track them as part of your vulnerability management lifecycle.
5. Follow advisories from the vendors of your critical products directly, since they are often complete before NVD analysis is.
6. Rescan after patching, and watch for record changes such as newly affected versions or rejected IDs.

How NetGuard helps

NetGuard's vulnerability scanner matches CVEs against what is actually installed, using authenticated and agentless scanning of servers, network devices, endpoints and databases, with CVE content updated regularly. Findings are prioritized using known-exploited vulnerabilities, public exploit availability and asset criticality, and rescans confirm that a fix really closed the issue. Reports are available in Persian and English, and the platform can run on-premises or in air-gapped networks. To see it on your own environment, contact us.

Frequently asked questions

What does CVE stand for?

CVE stands for Common Vulnerabilities and Exposures. It is a public list of identifiers for publicly disclosed security vulnerabilities, operated by MITRE and sponsored by CISA. Each entry gets an ID such as CVE-2021-44228, so vendors, scanners, advisories and security teams can refer to exactly the same flaw without confusion, regardless of which tool or language they use.

Who assigns CVE numbers?

CVE numbers are assigned by CVE Numbering Authorities (CNAs). These are organizations such as software vendors, open-source projects, national CERTs and bug bounty platforms that are authorized to issue IDs within their own scope. If the affected vendor is not a CNA, a root CNA or the CNA of Last Resort assigns the ID instead.

What is the difference between CVE and CVSS?

A CVE is a name for one specific vulnerability; CVSS is a score that describes how severe it is on a scale from 0 to 10. The CVE tells you which flaw you are dealing with, while CVSS, maintained by FIRST, helps estimate its technical impact. Neither tells you on its own whether the flaw is being exploited right now.

Does every vulnerability get a CVE?

No. CVEs are assigned to vulnerabilities in publicly available products that can be fixed independently. Misconfigurations on your own systems, weak passwords and bugs in internal, custom-built applications usually do not receive a CVE. That is why a security program needs configuration audits and hardening alongside CVE-based vulnerability scanning.

Does a zero-day vulnerability have a CVE?

Sometimes. A zero-day may have no CVE at all when it is first discovered being exploited, or the ID may be reserved while details are still private. Once the vendor publishes an advisory or fix, a full CVE record is usually published. Until then, rely on vendor guidance, mitigations and monitoring rather than CVE-based scanning.