CVE

What is a CVE?

A CVE is an entry in the Common Vulnerabilities and Exposures catalogue: one identifier for one publicly disclosed vulnerability in a specific product. The ID has the form CVE-YYYY-NNNNN, where the year is when the ID was reserved or published (not when the bug was introduced) and the number has four or more digits. The record contains a short description, the affected products and versions, references to advisories and fixes, and the name of the organisation that assigned it. CVE-2024-3094, the backdoor in xz-utils, is a well-known example.

The point of CVE is a shared name. Before it, every vendor and scanner described the same bug differently. Now an advisory, a scanner result, a patch note and a penetration test report can refer to the same ID.

Where is it defined?

The CVE Program is operated by MITRE, funded by the US government and governed by a board. IDs are assigned by CVE Numbering Authorities (CNAs): MITRE itself, national CERTs, and several hundred vendors and open-source projects that handle vulnerabilities in their own products under the CNA Operational Rules. The record format is a public JSON schema (CVE Record Format 5.x).

Scores are not part of CVE. The US National Vulnerability Database (NVD) enriches records with CVSS scores, CPE product identifiers and CWE weakness types. In the EU, NIS2 Article 12(2) tasks ENISA with a European vulnerability database; the EUVD went live in 2025 and mirrors CVE records with EU-specific context. The reporting obligations of the Cyber Resilience Act (Article 14) do not require a CVE, but a CVE is how the rest of the world will track the vulnerability you report.

What it means in practice

For a product manufacturer, CVE has two sides. On the inbound side, your dependency and firmware scanners match component versions against CVE records, which only works if you know your components: hence the SBOM. On the outbound side, when a vulnerability is found in your own product, someone has to assign a CVE. Becoming a CNA for your own products gives you control over timing and wording; otherwise MITRE or a CERT assigns it.

Things we see in projects:

• No CVE does not mean no vulnerability. Most bugs found in a penetration test of a custom application or an ECU never get a CVE, because they are specific to one product and are fixed without public disclosure. Embedded components are also under-reported: an RTOS or a Bluetooth stack with few public CVEs is usually under-tested, not clean.
• Version matching is coarse. A record says “versions before 2.4.1 are affected”; your distribution backported the fix into 2.3.7. Scanners flag it, and triage has to resolve it.
• The description is often thin. Many records say little more than “a buffer overflow in component X”. The references, not the summary, tell you whether it matters for your deployment.

Common misunderstandings

A CVE is not a severity rating; CVSS is. A CVE is not an exploit; a record exists whether or not anyone has weaponised the bug. And a CVE does not mean the vendor has a patch: records are published for unfixed bugs too, especially after a disclosure deadline has passed.