Who assigns CVE numbers?

Organisations authorised as CVE Numbering Authorities, which include many software vendors, open-source projects, research organisations, and national coordination bodies. Vendors that hold this role assign identifiers for vulnerabilities in their own products, usually as part of coordinated disclosure. The programme coordinates those authorities.

Does a CVE mean a vulnerability is serious?

No. The identifier is only a name. Severity is expressed separately through scoring systems such as CVSS, and real risk depends on whether you run the affected versions, whether the component is exposed, whether exploitation requires authentication, and whether exploitation is being observed.

Why do some CVEs have no details?

Identifiers can be reserved before public disclosure, so a record may exist with minimal description while coordinated disclosure is still in progress. Details are published when the vendor and reporter release the advisory, which can be days or weeks after reservation.

What Is a CVE?

A CVE, short for Common Vulnerabilities and Exposures, is a public identifier assigned to one specific vulnerability in a product, written as CVE plus the year and a sequence number. It gives advisories, scanners, and patch notes a shared name for the same flaw. It does not describe severity or your exposure.

What a CVE is and who assigns it

The CVE programme exists to give each publicly disclosed vulnerability a single stable identifier. Before shared identifiers, one flaw could appear under different names in a vendor advisory, a scanner, and a news article, and nobody could tell whether three reports meant three problems or one.

The format. CVE, the year of assignment or reservation, and a sequence number, such as CVE, the year of assignment, and a sequence number.

Who assigns them. Organisations authorised as CVE Numbering Authorities, which include many software vendors, open-source projects, research organisations, and national coordination bodies. A vendor that is a numbering authority assigns identifiers for its own products.

What a record contains. A description of the vulnerability, the affected products and versions, references to advisories and patches, and metadata such as the assigning authority and dates.

Reservation. An identifier can be reserved before details are public, which is why a CVE can appear in an advisory with a placeholder description while coordinated disclosure is still under way.

Related catalogues. National vulnerability databases enrich CVE records with scoring and classification data. Security tooling generally consumes both.

What a CVE is not

It is not a severity rating, a statement that you are affected, or a description of how the flaw is exploited. It is a name. A critical vulnerability in a component you do not run and a low-severity flaw in your main gateway both get identifiers, and only one is your problem.

Rejected and disputed records

Not every assigned identifier survives. Some are rejected as duplicates or as non-vulnerabilities, and some are disputed by the vendor, meaning the affected party does not accept that the behaviour is a flaw. Scanners occasionally report on records in those states, so a finding that looks alarming can end in a documented dispute rather than a patch.

How CVEs are used in practice

Scanners and inventories. Vulnerability scanners match software versions in your environment against CVE records, producing findings that reference identifiers.

Patch notes and advisories. Vendors list the CVEs a release fixes, which lets teams map a required upgrade to specific risks.

Tickets and audits. Referencing identifiers in tickets makes remediation auditable: the same identifier appears in the scanner finding, the change record, and the closure evidence.

Threat intelligence. Reports of active exploitation are usually keyed to identifiers, which is how a routine finding becomes urgent.

Regulatory and contractual reporting. Many frameworks expect vulnerability management records to reference identifiers rather than descriptions.

Communication between teams. The main daily value: a security engineer, a platform engineer, and a vendor's support team can all confirm they are discussing the same flaw.

Where identifiers show up first

For most teams the first sighting is a scanner finding or a vendor release note, not the CVE record itself. Both usually link back to the identifier, which is the fastest way to find the authoritative affected version list rather than relying on a tool's summary.

Reading a CVE sensibly

Check whether you actually run the affected versions. Advisories list version ranges precisely for a reason, and inventory quality determines whether you can answer quickly.

Check exposure, not just presence. The same vulnerable library behind a firewall in an internal tool and in an internet-facing service are different problems.

Check whether authentication is required. Unauthenticated remote code execution is the category that produces same-week incidents.

Check for known exploitation. Public exploitation reports and government exploited-vulnerability catalogues change priority more than a score does.

Expect records to change. Descriptions, affected version lists, and severity scores are updated after publication. Triaging once and never revisiting is a common failure.

Do not wait for an identifier to act. Vendors sometimes ship fixes before an identifier is published, and some issues never receive one. A patch with a credible security note is enough reason to move.

Watch the gap between disclosure and detection. Identifiers tell you a flaw exists. Whether it was used against you is a separate investigation.

Keeping a usable record

When closing a vulnerability ticket, keep the identifier, affected systems, the version deployed to fix it, and how you verified. Months later that record answers audit questions in minutes and shows whether a recurring finding is a regression or a new instance.

Frequently asked questions

What is a CVE in cyber security?: A Common Vulnerabilities and Exposures identifier, a public name for one specific vulnerability in a product, written as CVE plus the year and a sequence number. It lets advisories, scanners, patch notes, and tickets refer to the same flaw unambiguously.
Who assigns CVE numbers?: Organisations authorised as CVE Numbering Authorities, which include many software vendors, open-source projects, research organisations, and national coordination bodies. Vendors that hold this role assign identifiers for vulnerabilities in their own products, usually as part of coordinated disclosure. The programme coordinates those authorities.
Does a CVE mean a vulnerability is serious?: No. The identifier is only a name. Severity is expressed separately through scoring systems such as CVSS, and real risk depends on whether you run the affected versions, whether the component is exposed, whether exploitation requires authentication, and whether exploitation is being observed.
Why do some CVEs have no details?: Identifiers can be reserved before public disclosure, so a record may exist with minimal description while coordinated disclosure is still in progress. Details are published when the vendor and reporter release the advisory, which can be days or weeks after reservation.