Common Vulnerabilities and Exposures (CVE)

Common Vulnerabilities and Exposures (CVE) is a public identifier system, coordinated by MITRE, for uniquely naming and tracking individual software and hardware vulnerabilities. Each CVE record identifies a specific flaw in a specific product or version, given an identifier in the format CVE-YYYY-NNNNN, along with a brief description of the issue. CVE itself is not a severity rating or a database of exploit code; it is a naming convention that lets every vendor, researcher and security tool refer to the same vulnerability using the same identifier.

Before CVE existed, different vendors and researchers often used their own inconsistent names for the same underlying flaw, making it difficult to correlate advisories, scanner output and threat intelligence referring to the same issue. The CVE system solved that coordination problem by centralizing identifier assignment through a network of CVE Numbering Authorities, which include major software vendors, security researchers and coordination centers, all issuing IDs from the same shared registry.

A CVE record on its own contains minimal detail: an identifier, a short description, and references to further information. Severity scoring, technical detail and exploitation context come from related but separate systems: the National Vulnerability Database (NVD) enriches CVE records with CVSS severity scores and affected product mappings, the CISA KEV catalog flags which CVEs are confirmed to be actively exploited, and EPSS estimates the probability that a given CVE will be exploited in the near future. Together these systems form the backbone of how the entire security industry tracks, communicates about and prioritizes vulnerabilities.

In an exposure management context, CVE matching is what connects an externally observed piece of software, such as a specific version of a web server or a content management system identified through fingerprinting, to a known set of vulnerabilities. This matching is inherently probabilistic when done from the outside: a version banner might indicate a product is likely vulnerable to a specific CVE, but confirming exploitability with certainty typically requires more invasive testing. Mature platforms label these version-inferred matches with a confidence level rather than presenting them as a certainty, which avoids overwhelming remediation teams with false positives.

Not every security-relevant issue gets a CVE. Some categories of exposure, such as an exposed database with no authentication, a leaked credential, or a misconfigured cloud storage bucket, represent real risk without corresponding to a specific product vulnerability, so a complete exposure management program tracks both CVE-based findings and this broader category of configuration and exposure issues.