Cloud Parts

Common Vulnerabilities and Exposures (CVE)

A public ID such as CVE-2021-44228 that names one known vulnerability, so every scanner, advisory and patch note can point at the same flaw.

Live model
What you’re watchingTop row: a researcher reports a flaw to a CNA, which publishes a CVE record; NVD and CISA add scores, and advisory databases map it to package versions. Bottom row: every CI build goes through a scanner that keeps pulling those advisories. Most builds ship; one with an affected version (red) opens an alert to upgrade, patch or document why it doesn’t apply.

How it works

A CVE ID names one publicly disclosed vulnerability in the form CVE-YYYY-NNNN: the year the ID was reserved or the flaw made public (not when it was found), then four or more digits. IDs come from CVE Numbering Authorities (CNAs): vendors, open-source projects, CERTs, bug bounty platforms and researchers that the CVE Program authorizes for a scope, such as “All Apache Software Foundation issues only”. A CNA reserves an ID while a fix is prepared, then publishes a CVE Record with at least a short description, the affected products and versions, and public references. The record names the flaw; it isn’t a verdict. A severity score (CVSS), the type of mistake behind it (CWE, such as CWE-502 Deserialization of Untrusted Data) and product identifiers (CPE) come from the CNA or are added later: NIST’s National Vulnerability Database (NVD) enriches records, and CISA adds scores and flags flaws seen exploited in its Known Exploited Vulnerabilities (KEV) catalog. Package databases such as the GitHub Advisory Database and OSV.dev translate each CVE into package names and version ranges, keeping the CVE ID as an alias. Scanners such as Dependabot, Trivy or Amazon Inspector list the packages in your lockfile, container image or server, compare their versions with those ranges, and raise an alert on a match. You then upgrade, patch, or record why it doesn’t apply to you, for example in a VEX statement.

Think of it as

A car recall. The manufacturer files a recall with a number and lists the affected models and years; safety agencies add how dangerous it is and whether crashes have happened; your mechanic checks your car against the list and either fixes it or tells you your model isn’t affected.

Reach for it when

  • Tracking known flaws in the open-source packages and base images you ship: scan lockfiles and container images in CI and keep rescanning them in the registry
  • Ordering a long list of findings: start with CVEs in CISA’s KEV catalog, then weigh EPSS and CVSS against how exposed each system is
  • Talking about one flaw across teams, vendors and auditors: “are we affected by CVE-2021-44228?” has one answer per system
  • Shipping software other people run: publish your fixes with CVE IDs, through your own CNA or the one covering your project, and VEX statements for CVEs that don’t affect your product

Think twice when

  • Treating a CVSS base score as risk: FIRST says the base score measures severity and shouldn’t be used alone to assess risk
  • Blocking every build on every finding, including ones with no fix yet; tools offer ways out, such as Trivy’s --ignore-unfixed and Dependabot’s auto-triage rules for low-risk alerts
  • Assuming “no CVEs found” means safe: only publicly disclosed flaws get records, and scanners only match packages they can identify (Trivy, for one, skips self-compiled binaries)
  • Relying on NVD alone for scores and product data: since April 15, 2026, NIST only enriches prioritized CVEs, such as those in the KEV catalog, right away

A real example

On November 26, 2021, the Apache Software Foundation, the CNA for its own projects, reserved CVE-2021-44228 for a flaw in Log4j 2 found by Chen Zhaojun of Alibaba Cloud Security Team. The record went public on December 10, 2021: a crafted log message could make Log4j load and run code from an attacker’s LDAP server, fixed in 2.15.0 (Java 8), 2.12.2 (Java 7) and 2.3.1 (Java 6). The same day NVD scored it 10.0 Critical (CVSS 3.1) and CISA added it to the KEV catalog, giving federal agencies until December 24. GitHub’s advisory GHSA-jfh8-c2jp-5v3q maps it to the Maven package org.apache.logging.log4j:log4j-core, versions 2.13.0 up to 2.15.0 plus two older ranges, so a scanner reading a Java service’s dependency tree with log4j-core 2.14.1 flagged it at once. Teams had to upgrade more than once: the 2.15.0 fix proved incomplete (CVE-2021-45046, fixed in 2.16.0), more CVEs followed, and by December 28 CISA was urging 2.17.1. As of October 12, 2026, EPSS gives it a 0.99999 probability of exploitation in the next 30 days, the top percentile.

What each provider calls it

AWS
Amazon Inspector (scans EC2 instances, container images in Amazon ECR and Lambda functions, and rescans when a new CVE affects them); Amazon ECR basic and enhanced image scanning
Google Cloud
Artifact Analysis (formerly Container Analysis): automatic and on-demand vulnerability scanning of images in Artifact Registry; findings also in Security Command Center
Azure
Microsoft Defender for Cloud (Defender for Containers scans registry and running images with Microsoft Defender Vulnerability Management); Microsoft Defender Vulnerability Management for devices
Open source & others
Trivy, Grype (Apache 2.0), OSV-Scanner with the OSV.dev database; hosted: GitHub Dependabot alerts and the GitHub Advisory Database, Snyk Open Source

CVE and the systems around it#

A CVE ID only names the flaw. Each question you ask about it next is answered by a separate system, run by someone else, that keys on the CVE ID.

SystemAnswersRun byFor CVE-2021-44228
CVEWhich vulnerability is this?The CVE Program, sponsored by CISA with MITRE as Secretariat; IDs assigned by CNAsAssigned by the Apache Software Foundation
CWEWhat kind of mistake caused it?The CWE Program, sponsored by CISA and operated by MITRECWE-502, CWE-400 and CWE-20 from Apache; NVD adds CWE-917
CVSSHow bad is it in the reasonable worst case, from 0 to 10?FIRST defines it; the CNA, NVD or CISA supplies the scores10.0 Critical (CVSS 3.1)
CPEWhich products and versions, in a machine-readable name?NIST (CPE 2.3); NVD attaches CPE matches to recordscpe:2.3:a:apache:log4j, 2.13.0 up to 2.15.0, plus older ranges
OSV, GHSAWhich package versions in a registry such as Maven or npm?OSV.dev and the GitHub Advisory Database, in the OSV formatGHSA-jfh8-c2jp-5v3q: log4j-core 2.13.0 up to 2.15.0, and two older ranges
KEVHas anyone exploited it in the wild?CISAAdded December 10, 2021; known ransomware use
EPSSHow likely is exploitation in the next 30 days?FIRST’s EPSS group; scores generated daily by Empirical Security0.99999 on October 12, 2026
VEXIs this particular product affected?The product’s supplier, in formats such as OpenVEX or CSAF VEXA product shipping only log4j-api, without log4j-core, can say not_affected
  • The CNA’s own record for CVE-2021-44228 rates it only “critical”; the 10.0 score comes from NVD and from CISA’s Authorized Data Publisher container.
  • Apache says applications using only the log4j-api JAR without log4j-core are not impacted. OpenVEX’s component_not_present justification exists for statements like that.

Who runs it, and the life of a record#

The CVE Program is sponsored by CISA, part of the U.S. Department of Homeland Security, which funds a federally funded research and development center operated by MITRE to run it; MITRE is the Secretariat that keeps the infrastructure running (as of October 12, 2026). A CVE Board sets the rules. Under it, two Top-Level Roots, CISA and MITRE, oversee eight Roots, among them Google, Red Hat, ENISA and JPCERT/CC, and those oversee the CNAs. As of October 12, 2026, cve.org lists 555 CNAs, including 3 CNAs of Last Resort that take flaws no other CNA covers. Joining costs nothing and needs no contract; vendors such as Microsoft and projects such as the Linux kernel assign IDs for their own products.

A record starts as Reserved: the CNA holds the ID while the fix is coordinated, and nothing is public yet. It becomes Published once it has the minimum data. If the ID should not be used after all, it becomes Rejected and stays on the list so nobody reuses it. When a vendor disagrees that something is a vulnerability at all, the record can carry a DISPUTED tag instead; the program doesn’t decide who is right and leaves the record up.

Volume keeps climbing. CNAs published 20,709 records in the second quarter of 2026, up from 15,176 in the first, and reserved 33,164 IDs. The program’s own report puts a spike in reservations in the second quarter of 2025 down to community worry about a possible gap in funding, and the 2026 spike down to AI-driven vulnerability discovery.

Enrichment is where the strain shows. NIST says CVE submissions rose 263% between 2020 and 2025 and that the NVD built a backlog of unenriched CVEs from early 2024. On April 15, 2026, it switched to enriching only prioritized CVEs (those in the KEV catalog, software used by the federal government, and critical software) and moved backlogged CVEs published before March 1, 2026, to “Not Scheduled”. It also stopped adding its own severity score when the CNA already gave one. That shifts the work to CNAs: in October 2026, 281 of them provided CVSS and CWE in at least 98% of their recent records. Scanners already hedge: Trivy takes severity from the OS vendor or other sources when NVD hasn’t scored a CVE yet.

In code · json

// Trimmed excerpt of the official record for CVE-2021-44228 in CVE JSON 5 format; some fields left out, … marks cut lists
{
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "cveMetadata": {
    "cveId": "CVE-2021-44228",
    "state": "PUBLISHED",
    "assignerShortName": "apache",
    "dateReserved": "2021-11-26T00:00:00.000Z",
    "datePublished": "2021-12-10T00:00:00.000Z"
  },
  "containers": {
    "cna": {
      "title": "Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints",
      "descriptions": [ … ],
      "affected": [{
        "vendor": "Apache Software Foundation",
        "product": "Apache Log4j2",
        "versions": [{
          "version": "2.0-beta9", "status": "affected", "lessThan": "log4j-core*", "versionType": "custom",
          "changes": [
            { "at": "2.3.1", "status": "unaffected" }, { "at": "2.4", "status": "affected" },
            { "at": "2.12.2", "status": "unaffected" }, { "at": "2.13.0", "status": "affected" },
            { "at": "2.15.0", "status": "unaffected" }
          ]
        }]
      }],
      "problemTypes": [{ "descriptions": [{ "type": "CWE", "lang": "en", "description": "CWE-502 Deserialization of Untrusted Data", "cweId": "CWE-502" }] }, …],
      "metrics": [{ "other": { "type": "unknown", "content": { "other": "critical" } } }],
      "references": [ … 53 links: Apache’s security page, vendor advisories … ], …
    },
    "adp": [{
      "title": "CISA ADP Vulnrichment",
      "metrics": [
        { "cvssV3_1": { "baseScore": 10, "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H", … } },
        { "other": { "type": "ssvc", "content": { "options": [{ "Exploitation": "active" }, { "Automatable": "yes" }, { "Technical Impact": "total" }], … } } },
        { "other": { "type": "kev", "content": { "dateAdded": "2021-12-10", … } } }
      ]
    }, …]
  }
}

Often confused with

Package managersContainersCI/CD pipelinesLinters, formatters and type checkersSecrets managementIncident management
Where it came from1999–2026

In the late 1990s every security tool kept its own list of vulnerabilities under its own names. In a January 1999 paper, MITRE’s David E. Mann and Steven M. Christey gave an example: a 1991 hole that let attackers guess NFS file handles was nfs-guess in the ISS X-Force database, “NFS file handle guessing check” in CyberCop Scanner 2.4, and one item in CERT Advisory CA-91.21. Telling whether two tools had found the same problem meant reading descriptions by hand. They proposed a “Common Vulnerability Enumeration”: a public list that gives each known vulnerability one standard, unique name, independent of any tool’s view of it.

The idea was presented at Purdue University that month. A working group, later a 19-member editorial board, wrote the first 321 records, and the CVE List launched publicly in September 1999. Vendors put CVE IDs in their advisories, NIST recommended the scheme to U.S. agencies in 2002, and in 2005 NIST launched the National Vulnerability Database on top of the list. The same year FIRST became custodian of the Common Vulnerability Scoring System, so severity became a separate layer on the shared name.

From 2016 the program actively expanded the number of CVE Numbering Authorities, and every record is now added by a CNA. Records moved to the structured CVE JSON 5.0 format in 2022; in it, the CNA’s data and that of authorized data publishers such as CISA sit in separate containers. CISA’s KEV catalog, created in November 2021, and FIRST’s EPSS added answers about exploitation that a name and a severity score can’t give. Growth brought strain: by April 2026 NIST had stopped trying to enrich every CVE in the NVD.

Why it’s built this way

A name, not a database
The 1999 paper wanted an enumeration independent of the many views of a vulnerability: an IDS signature, a scanner probe, a taxonomy. Independence from those views, the authors argued, would keep the list stable, while each tool keeps its own details and links them by ID.
Public, with no distribution restrictions
The authors argued a common list must be free to share, or tools and databases couldn’t exchange data through it. CVE Records and NVD data remain free to use.
Assignment spread across CNAs
Vendors, open-source projects and researchers already handle disclosure for their own products. Letting them assign IDs within a scope, with no fee or contract, means the record comes from whoever knows the product, while CNAs of Last Resort catch the rest.
Severity and exploitation kept outside the ID
The CVE Program doesn’t assign severity scores. CVSS rates severity, KEV records actual exploitation and EPSS predicts it, each run by a different group and updated on its own schedule, all keyed on the same ID.

Timeline

  1. 1999

    MITRE proposes a common enumeration in January; the CVE List launches in September with 321 records

  2. 2005

    NIST launches the National Vulnerability Database; FIRST becomes custodian of CVSS in April

  3. 2007

    CVSS version 2 released in June

  4. 2016

    The CVE Program starts actively expanding the number of CNAs

  5. 2021

    CISA creates the KEV catalog on November 3; Log4Shell, CVE-2021-44228, is published on December 10

  6. 2022

    cve.org starts displaying records in CVE JSON 5.0 in October

  7. 2023

    CVSS v4.0 released in November

  8. 2026

    NVD switches to risk-based enrichment on April 15; CISA’s BOD 26-04 carries the KEV criteria forward on June 10

Sources44

Improve this page on GitHub