What is a CVE, and why doesn't it tell you how urgent a flaw is?

A CVE (Common Vulnerabilities and Exposures) is the unique public identifier assigned to a known security vulnerability, meaning a flaw in software or a device that an attacker can exploit. It takes the form CVE-year-number, for example CVE-2021-44228, and works like a Social Security number for the flaw, so vendors, scanning tools and IT teams know they are talking about the same thing. The catalog is maintained by the CVE Program, sponsored by the US cybersecurity agency CISA and operated by MITRE, a nonprofit. The identifiers are assigned by hundreds of authorized organizations, the CVE Numbering Authorities (CNAs), among them software vendors, open source projects and public incident response teams, each within its own agreed scope. A published record contains the identifier, the affected product, a description and at least one public reference. By design, it carries no judgment on how urgent the flaw is for any particular company.

See also: Patch management · The process by which a company discovers, prioritizes, tests and installs security updates for its systems, measured in days of exposure.

What a CVE does not tell you

The costliest mistake is reading a CVE as a priority: even the year in the name, the CVE Program explains, marks when the ID was reserved or the flaw made public, not when it was discovered. Three other sources tell you how much the flaw matters. Technical severity is the CVSS score (Common Vulnerability Scoring System) from FIRST, the global forum of security teams. In version 4.0 it runs from 0 to 10 and describes the reasonable worst case; the specification itself asks users to adjust it for their own context. Real-world exploitation is recorded in CISA's Known Exploited Vulnerabilities (KEV) catalog, which only admits flaws with a CVE and reliable evidence of attacks, and which underpins prioritization in patch management. The probability of exploitation over the next 30 days is estimated daily by EPSS, a statistical model also from FIRST.

A more fragile system than it looks

Many tools read CVEs through NIST's National Vulnerability Database (NVD), which adds scores and affected products to them. NIST has acknowledged a backlog that has been growing since early 2024 and was never cleared, with CVE submissions up 263% between 2020 and 2025. Since April 15, 2026, NIST has prioritized CVEs that are in the KEV catalog or affect software used by the federal government or critical software, leaving the rest unscheduled. Europe has its own aggregator, ENISA's European Vulnerability Database (EUVD), required by the NIS2 directive and live since May 13, 2025: it collects CVEs alongside advisories from national teams rather than replacing them.

An enterprise example

A manufacturer gets four hundred open CVEs from its scanner, sorted by CVSS score. The IT team starts at the top and spends two weeks on 9s and 10s in libraries unreachable from outside, while a 7.5 already in the KEV catalog stays open on the VPN server. The right question was which CVEs are already being exploited and affect exposed components the company actually runs. Answering it takes an SBOM, the inventory of each program's components: without one, every new CVE starts a manual hunt.

Why it matters for decision makers

The CVE is the shared vocabulary of security, not the yardstick. It pays to ask vendors for the CVEs in their products along with a component inventory, and for reports ranked by exploitation and exposure as well as by CVSS. Manufacturers of products with digital elements sold in the EU also have an obligation: since September 11, 2026, Article 14 of the Cyber Resilience Act has required an early warning within 24 hours of the manufacturer becoming aware of an actively exploited vulnerability in its product, even if no CVE has yet been published for that flaw.