What is a CVE? —
vulnerability IDs, explained like you're new here.

You've seen the headlines: "critical CVE under active exploitation," "patch now for CVE-2021-44228." You've seen scanners light up red with lists of them. But if nobody has ever actually explained what a CVE is — who creates them, what the numbers mean, which ones matter, and what happens when software stops receiving fixes for them — this guide is for you. Zero prior knowledge assumed.

The one-sentence version

A CVE (Common Vulnerabilities and Exposures entry) is a catalog number for a publicly known security flaw in a specific piece of software — nothing more, nothing less. CVE-2021-44228 is not an attack, a virus, or an event. It is an entry in a public registry that says: "this software, in these versions, contains this weakness."

The analogy that holds up best: CVEs are recall notices for software. When a carmaker discovers a faulty airbag, the recall gets a number, a description of affected models, and a severity. CVEs do the same for code. And just like recalls, the notice itself is neutral — what matters is whether your model is affected and whether a fix exists for it.

The system exists so everyone is talking about the same flaw. Before CVE launched in 1999, the same bug might have five names across five security vendors. Today, one flaw gets one ID, and every scanner, vendor advisory, and news article can point at it unambiguously.

Who hands out CVE IDs

The CVE program is run by MITRE, a US nonprofit, funded by the US government. But MITRE doesn't find the bugs. IDs are assigned by CVE Numbering Authorities (CNAs) — several hundred organizations authorized to issue CVE IDs for flaws in their own territory. Microsoft is a CNA for Microsoft products, Red Hat for its ecosystem, GitHub for projects hosted there. When a researcher finds a flaw, they report it to the relevant CNA, which assigns the ID and coordinates disclosure.

Anatomy of a CVE ID

Take CVE-2021-44228 — the Log4j flaw known as Log4Shell:

• CVE — the registry prefix, always the same.
• 2021 — the year the ID was assigned. Not necessarily the year the bug was introduced (Log4Shell's code shipped in 2013) or the year you'll be exploited by it (still happening today).
• 44228 — a sequence number with no hidden meaning. Tens of thousands of CVEs are published every year, so these run five digits and beyond.

Each entry records affected products and version ranges, a technical description of the weakness, references to advisories and patches, and usually a severity score — which brings us to CVSS.

What a CVE is not

Three misconceptions cause most of the confusion:

A CVE is not an incident. "We have 200 CVEs" means your software contains 200 known flaws, not that you've been breached 200 times. It's a measure of exposure, not of damage.

A CVE is not automatically dangerous. Most CVEs are never exploited by anyone. Many require conditions your deployment doesn't meet — a feature you disabled, a network position attackers can't reach. This is why blind CVE-count panic wastes security budgets, and why triage (below) matters more than totals.

The CVE list is not complete. A flaw only gets a CVE when someone finds it, reports it, and a CNA processes it. Software with zero CVEs is not necessarily safe — it may just mean nobody is looking. This matters enormously for abandoned software: when a project loses its maintainers, researchers stop auditing it too, so its CVE feed goes quiet at exactly the moment its real risk starts compounding. Silence is not safety.

CVSS: the severity score (and how it misleads)

Most CVEs carry a CVSS score (Common Vulnerability Scoring System, maintained by FIRST) from 0.0 to 10.0: roughly, 9.0+ is "critical," 7.0–8.9 "high," 4.0–6.9 "medium," below that "low." The score is computed from questions like: can it be exploited over the network? Does the attacker need to be logged in? Does a user have to click something? Does it fully compromise the system?

CVSS is useful shorthand and deeply misleading if used alone:

• It measures theoretical worst case, not likelihood. A 9.8 that no attacker has ever weaponized can matter less in practice than a 7.5 being mass-exploited this week.
• It knows nothing about your environment. A critical flaw in an internal admin tool behind a VPN is a different animal than the same flaw on your public login page.
• Score inflation is real. A large share of newly published CVEs land in high/critical territory, so "patch all criticals immediately" becomes an unbounded workload.

The three lists that actually matter

NVD — the encyclopedia

The National Vulnerability Database, run by NIST, is where CVE entries get enriched with scores and affected-product data in machine-readable form. It's the database most scanners query. Think of it as the full encyclopedia: authoritative, comprehensive, and far too big to "just fix everything in."

CISA KEV — the shortlist that ranks everything else

The Known Exploited Vulnerabilities catalog, run by the US cybersecurity agency CISA, lists only CVEs with confirmed real-world exploitation — around 1,400 entries versus NVD's quarter-million. If a CVE affecting your stack is on KEV, it goes to the top of the pile, period. US federal agencies are legally required to patch KEV entries on a deadline; treat that as a strong hint. (Our EOL Risk Score uses KEV presence as a scoring factor for exactly this reason.)

EPSS — the odds-maker

EPSS (Exploit Prediction Scoring System) estimates the probability that a CVE will be exploited in the next 30 days, based on observed attacker behavior. It's the bridge between "theoretically bad" (CVSS) and "confirmed bad" (KEV) — useful for ranking the thousands of CVEs that sit between those poles.

The life of a CVE, hour by hour

Understanding the timeline explains why patching speed — and patch availability — matter so much. Log4Shell is the canonical example:

• Discovery. A researcher finds the flaw and reports it privately (Nov 24, 2021). Coordinated disclosure begins: the maintainers get time to build a fix before the world knows.
• Disclosure + patch. The CVE publishes and the fixed version ships (Dec 9–10, 2021). From this moment the flaw is public knowledge — including to attackers.
• Proof-of-concept. Working exploit code appears on GitHub within hours. Anyone can now copy-paste the attack.
• Mass scanning. Within days, automated scanners are probing the entire internet for vulnerable versions. Exploitation stops being targeted and becomes weather — it hits everything that's exposed, indiscriminately.
• The long tail. Years later, the same CVE still ranks among the most-exploited, because unpatched copies persist in forgotten systems. Attackers don't retire exploits that keep working.

The window between "patch available" and "mass exploitation" is now routinely measured in days. That's survivable when a patch exists for your version. Which raises the question this whole site exists to answer —

Where CVEs meet end-of-life software

Everything above assumes one thing: that a patch is coming. When software passes its end-of-life date, that assumption dies. The recall notices keep being published; the manufacturer has stopped fixing your model. Every CVE that applies to an EOL version is permanent.

This creates what we call the CVE blind spot, and it's genuinely worse than a zero-day in one respect: with a zero-day, at least nobody else knows either. With an EOL CVE, the flaw is public — documented, scored, often with ready-made exploit code — and your only remedies are migration or extended support. Real examples from our own catalog:

• dom4j 1.6.1 — a 2005 Java library still embedded in legacy stacks, permanently vulnerable to a critical XML flaw (CVE-2020-10683) that will never be fixed in the 1.x line.
• H2 Database 1.4.x — ended in 2019; RCE-class flaws disclosed in 2022 apply to it forever.
• SnakeYAML 1.x — its deserialization flaw (CVE-2022-1471) was fixed by changing defaults in 2.0; the 1.x line everyone still ships transitively stays vulnerable.
• YUI — formally discontinued by Yahoo in 2014; every flaw found since is unfixable by design.

What to actually do about CVEs

A sane, beginner-friendly triage that security teams converge on:

• 1. KEV first. Anything in your stack on CISA's exploited list gets patched now. This list is short and non-negotiable.
• 2. Internet-facing next. A medium flaw on your public edge beats a critical one on an isolated internal box.
• 3. Use EPSS to rank the rest. Probability of exploitation orders the long middle of the list better than raw CVSS.
• 4. Fix the class, not the instance. The single highest-leverage move is keeping software in support — a current version gets tomorrow's patches automatically. Chasing individual CVEs on an EOL platform is bailing a boat with a hole in it.

That last point is the whole thesis of this site: version currency is vulnerability management. Check any product's support status in seconds with the EOL Checker, see how we weight KEV exposure and lifecycle status in the EOL Risk Score methodology, or start from the beginner's guide to EOL software if terms like runtime and LTS are still fuzzy. And when a CVE lands in something you can't upgrade, here are your actual options.