What is a CVE?

CVE stands for Common Vulnerabilities and Exposures. The CVE Program assigns unique identifiers to publicly known vulnerabilities, such as CVE-2021-44228 for Log4Shell. Vendors, security researchers, scanners, advisories and administrators can use the identifier to refer unambiguously to the same issue. A CVE is initially a reference, however-not a patch or a complete risk assessment.

How is a CVE identifier structured?

An identifier consists of the CVE prefix, a year and a sequence number, for example CVE-2025-12345. The year generally indicates assignment or reservation and does not have to match discovery, disclosure or the first attack. The sequence contains at least four digits and can be longer as the number of records grows. The identifier itself reveals neither vendor, product, weakness type nor severity.

What information does a CVE Record contain?

A published CVE Record contains at least the identifier, a brief description, affected products and versions, and public references. Depending on the issuing organization, it may include precise version ranges, CWE mappings, CVSS scores, workarounds or additional vendor information. Linked advisories are often more important than the short description because they explain prerequisites, updates and concrete remediation in greater detail.

How is a CVE created?

1. Discover the vulnerability: A vendor, researcher or other party identifies a security problem.
2. Determine responsibility: A CVE Numbering Authority (CNA), often the affected vendor or a coordination center, handles the request.
3. Reserve the identifier: The CNA assigns a CVE ID early so that participants can use one reference.
4. Coordinate disclosure: Affected versions, remediation, timing and public information are established.
5. Publish the Record: Once required information is available, the CNA submits the entry to the CVE List.
6. Update the entry: Further versions, references or corrections may be added later.

Not every discovered vulnerability immediately receives a public CVE. Details often remain confidential during coordinated disclosure so that a vendor can prepare a patch. For libraries and reused components, participants may also need to determine whether the root cause belongs to the component or only to its integration in a product.

What do RESERVED and REJECTED mean?

• RESERVED:
  A CNA has reserved the identifier but has not yet published usable details. This does not prove that information is being improperly withheld or that the issue is especially critical.
• PUBLISHED:
  The Record contains the required information and is publicly available in the CVE List.
• REJECTED:
  The identifier should no longer be used, for example because it is a duplicate or was assigned incorrectly. It remains visible so old references can be understood.

How do CVE, NVD, CWE and CVSS differ?

These data may come from different organizations and change at different times. A vendor may assess a different CVSS vector from an external database because it assumes different prerequisites. Teams should record the source, version and rationale rather than copying a single number without context.

Does a CVE automatically represent high risk?

No. A CVE initially states that a concrete public vulnerability has a common reference. Whether an organization is affected depends on the product, exact version, configuration and use. A vulnerable library might be installed even though the affected code is unreachable. Conversely, a medium-severity vulnerability in a public, business-critical system may deserve urgent treatment.

A very high CVSS score also does not automatically mean that attackers are exploiting the vulnerability. The CISA Known Exploited Vulnerabilities Catalog identifies evidence of exploitation in the wild. EPSS provides a daily estimate of the probability that exploitation activity for a CVE will be observed in the next 30 days. Both signals add useful information but do not replace organizational context.

How should organizations prioritize CVEs?

1. Confirm applicability: Match product, exact version and possibly the vulnerable function against a reliable software and asset inventory.
2. Assess exposure: Examine reachability, required privileges, enabled features and compensating controls.
3. Review the threat: Consider public exploits, known active exploitation, EPSS and relevant threat intelligence.
4. Determine impact: Evaluate affected data, business processes, possible attack chains and recoverability.
5. Select treatment: Record the patch, configuration change, workaround, isolation or justified acceptance with an owner and date.
6. Verify success: Retest after the change and do not close scanner findings without evidence.

A vulnerability scanner can identify known versions and characteristics. False positives, backports and incomplete detection remain possible. A scanner finding is therefore the beginning of technical assessment, not its conclusion.

What are the limitations of the CVE system?

Not every vulnerability has a CVE, and the absence of an identifier does not prove that a product is secure. Misconfigurations, internal applications, business-logic flaws and undisclosed vulnerabilities may sit outside the list. A CVE Record can be incomplete initially and corrected later. An installed package version is not always conclusive either, because vendors may backport security fixes without changing the visible major version.

CVE provides a shared reference and is therefore a central part of vulnerability management. It becomes effective only in combination with a current asset inventory, vendor information, technical validation, threat signals and traceable risk prioritization.