Every time a software vulnerability is discovered and publicly disclosed, it receives a CVE identifier. That identifier — a number like CVE-2021-44228 — becomes the universal reference for that specific flaw. Security teams use it to track patching. Vendors use it to issue advisories. Threat intelligence platforms use it to correlate attack activity. Attackers use it to find targets that have not yet patched.

Understanding CVEs is foundational knowledge for anyone in security — and increasingly important for IT professionals and system administrators who need to make informed patching decisions. This guide explains what CVEs are, how to read them, how severity is scored, and how to use CVE data practically.

What CVE actually stands for

CVE stands for Common Vulnerabilities and Exposures. The program is maintained by MITRE Corporation and funded by the US Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA). It has been running since 1999 and has assigned identifiers to over 200,000 vulnerabilities.

The purpose is standardization. Before CVE, different security vendors referred to the same vulnerability using different names and identifiers. A coordinated response to a critical flaw was difficult when everyone was talking about it differently. CVE provides a common language — one identifier that everyone uses for the same flaw.

Anatomy of a CVE entry

Here is a real CVE entry — Log4Shell, one of the most serious vulnerabilities ever discovered — annotated to explain each field.

CVE-2021-44228
CVSS SCORE
10.0 — CRITICAL
AFFECTED SOFTWARE
Apache Log4j2 versions 2.0-beta9 through 2.14.1
VULNERABILITY TYPE
Remote Code Execution (RCE) via JNDI injection in log messages
DESCRIPTION
Apache Log4j2 does not protect against attacker-controlled LDAP and other JNDI-related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
PUBLISHED
December 10, 2021
EXPLOITED IN WILD
YES — Added to CISA KEV catalog
PATCH AVAILABLE
Yes — upgrade to Log4j2 2.15.0 or later

Log4Shell was particularly significant because Log4j2 is embedded in thousands of applications — from enterprise software to consumer products to critical infrastructure. A single vulnerability in a logging library affected an enormous percentage of internet-connected systems globally.

The CVSS score — how severity is measured

The Common Vulnerability Scoring System (CVSS) is the standard for measuring vulnerability severity. It produces a score from 0.0 to 10.0 based on characteristics of the vulnerability — how easy it is to exploit, what access is required, what the impact is if exploited.

CVSS SEVERITY SCALE
0.0 5.0 10.0
NONE
0.0
No vulnerability — informational only
LOW
0.1 – 3.9
Limited impact, complex exploitation, or requires significant privileges
MEDIUM
4.0 – 6.9
Meaningful impact but requires some conditions — authentication, local access, user interaction
HIGH
7.0 – 8.9
Significant impact — remote exploitation, high confidentiality or integrity loss. Patch urgently.
CRITICAL
9.0 – 10.0
Maximum severity — unauthenticated remote code execution, no user interaction required. Patch immediately.

CVSS score is important but not the only factor in prioritization. A Critical CVSS score on software you do not run is irrelevant. A Medium CVSS score on a vulnerability being actively exploited against your specific environment may be your highest priority. CVSS tells you about the inherent severity of a vulnerability — your environment determines its actual risk to you.

CVE versus KEV — the distinction that matters most

Approximately 25,000 new CVEs are published every year. No organization can patch everything immediately. The practical question is: which ones actually matter right now?

CISA's Known Exploited Vulnerabilities (KEV) catalog answers this question. The KEV catalog lists CVEs that have been confirmed as actively exploited in real attacks in the wild. A vulnerability on the KEV catalog is not theoretical — it is being used to compromise systems right now.

For US federal agencies, CISA mandates remediation of KEV catalog vulnerabilities within defined timeframes — typically 2 weeks for most vulnerabilities, shorter for the most critical. For everyone else, the KEV catalog is the most reliable signal for which CVEs to prioritize regardless of CVSS score.

The practical rule: Critical CVSS + active exploitation = patch today. High CVSS + active exploitation = patch this week. Critical CVSS + no known exploitation = patch this sprint. Everything else fits into normal patching cycles.

"A CVSS 10.0 vulnerability in software you do not run is not your problem. A CVSS 6.5 vulnerability in your VPN that is actively being exploited is your highest priority. Context determines risk."

How CVEs are assigned and published

THE CVE LIFECYCLE
1
DiscoveryA security researcher, vendor, or attacker finds a vulnerability. The discoverer may report it to the vendor directly (responsible disclosure) or to a CVE Numbering Authority (CNA).
2
CVE ID reservationA CVE ID is reserved — the number is assigned before full details are published. This allows vendors time to develop a patch before the vulnerability is publicly disclosed.
3
Patch developmentThe affected vendor develops and tests a fix. Coordinated disclosure timelines — typically 90 days — are negotiated between the researcher and vendor.
4
Public disclosureThe CVE is published in the National Vulnerability Database (NVD) with full details — description, affected versions, CVSS score, references. The patch is released simultaneously.
5
Exploitation windowBetween publication and patching, exposed systems are vulnerable. Attackers scan for unpatched systems immediately after CVE publication. Speed of patching is the critical variable.

Where to track CVEs

NVD — National Vulnerability Database
nvd.nist.gov
The authoritative CVE database. Every published CVE with full details, CVSS scores, and references. The primary source.
CISA KEV Catalog
cisa.gov/known-exploited-vulnerabilities-catalog
The list of CVEs confirmed as actively exploited. Your top priority patching list. Updated continuously.
MyCyberBrief Intel Feed
intel.mycyberbrief.com
Critical CVEs covered as they are published, with plain-English explanation of impact and remediation. Updated every 15 minutes.
CVE Mitre
cve.mitre.org
The original CVE program maintained by MITRE. Searchable database and the source of CVE ID assignments.

CVEs in practice — what security teams actually do

For security teams, CVE management is a continuous operational process. New CVEs are published daily. The challenge is not finding them — it is deciding which ones require immediate action and which can wait for the next patching cycle.

Mature organizations use vulnerability management platforms — Tenable, Qualys, Rapid7 — that automatically scan their environment, match findings to CVEs, and prioritize based on CVSS score, KEV status, and asset criticality. The output is a prioritized remediation list that tells the team what to fix in what order.

Smaller organizations without dedicated vulnerability management tools can follow a simpler process: subscribe to vendor security advisories for the products they run, monitor the CISA KEV catalog for additions, and maintain a patching cadence that addresses Critical and High severity CVEs within defined timeframes.

The single most important habit around CVE management is speed. The time between a CVE being published and attackers having working exploits is measured in hours for the most critical vulnerabilities. Organizations that patch within 24-48 hours of a Critical CVE publication are substantially safer than those that patch weekly or monthly.