What is CVE?

CVE in plain English

Almost every book on sale has an ISBN. Whether in a bookstore, online, or at the library, that number makes it clear exactly which book is meant. CVE does the same for security vulnerabilities. The abbreviation stands for “Common Vulnerabilities and Exposures.”

A vulnerability is a flaw in software or hardware that attackers can exploit. Once such a flaw becomes publicly known, it usually receives a CVE number. The corresponding entry briefly describes which product is affected and in which versions. It also points to further sources, such as the vendor’s security advisories.

A well-known example is CVE-2021-44228, better known as “Log4Shell.” The vulnerability was found in Log4j, a widely used library for the Java programming language – in other words, a ready-made building block that a huge number of applications rely on. Thanks to the unique identifier, organizations around the world could check precisely whether they were affected. Incidentally, the number alone does not tell you how dangerous a vulnerability is. That requires a separate rating, usually based on the CVSS standard.

How the CVE system works

The system is run by the CVE Program, which coordinates how the numbers are assigned. They are issued by numerous authorized organizations worldwide, known as CVE Numbering Authorities (CNAs). These include software vendors, security companies, and computer emergency response teams (CERTs). A vulnerability typically makes its way into the database like this:

1. Discovery: A security researcher, a vendor, or a testing team finds a vulnerability and reports it confidentially to the vendor.
2. Reservation: A CNA reserves an identifier. It consists of “CVE,” a year, and a sequential number. The year usually indicates when the number was reserved – not when the vulnerability was introduced or discovered.
3. Publication: As soon as an update is available or the vulnerability is public anyway, the entry is published with a description and the affected versions.
4. Enrichment: Vulnerability databases add a CVSS score and often a note on whether the vulnerability is already being actively exploited. Since 2025, the EU Agency for Cybersecurity (ENISA) has also operated the European Vulnerability Database (EUVD), which references CVE identifiers.
5. Matching: A vulnerability scan compares the installed software versions against these databases and reports open CVEs.

Important: not every vulnerability receives a CVE number. Flaws in custom-built software, such as your own online shop, usually don’t get one. A scanner that only checks for known CVEs will therefore not find them.

A practical example

Here’s a typical scenario: A mid-sized furniture manufacturer reads a security alert about a critical vulnerability in a widely used VPN gateway. Employees use devices like this to connect to the corporate network while on the road. The IT manager looks up the CVE number in the vendor’s security advisories, which state exactly which versions are affected and which update fixes the problem.

A check against the company’s own inventory shows that the device at the second site is still running an affected version. It is updated the same day. Without the unique identifier, the team would first have had to figure out whether the alert even applied to their product. Attackers use exactly that time to scan the internet for vulnerable devices.

Why does this matter for businesses?

Many successful attacks don’t rely on unknown tricks but on known vulnerabilities for which an update has long been available. Once a CVE is published, attackers know about the vulnerability too. Publicly available exploits – ready-made attack tools – often follow soon after. Automated searches for vulnerable systems then frequently begin very quickly.

CVE numbers make this risk manageable. They link security alerts, vendor advisories, and scan results unambiguously. In addition, frameworks such as NIS2 and ISO/IEC 27001 require a structured approach to handling vulnerabilities. If you track CVEs systematically, you can show customers, auditors, and insurers that known vulnerabilities are not left unaddressed.

How to protect your organization

• Keep an inventory: Record all systems, programs, and versions. That’s the only way to match CVE alerts to your environment.
• Follow security alerts: Subscribe to your vendors’ security advisories and to the warnings issued by the BSI (Germany’s Federal Office for Information Security).
• Prioritize by risk: Critical vulnerabilities in internet-facing systems take priority – especially if they are already being actively exploited.
• Update promptly: In your patch management – the structured process of installing updates – set fixed deadlines based on severity.
• Scan regularly: Check automatically where known CVEs are still open.
• Test beyond CVEs: Have custom applications and configurations reviewed manually as well. CVE databases won’t help you there.

How Rootsektor can help

In our vulnerability assessment, we check your systems for known CVEs, missing updates, and insecure configurations. We verify the relevant findings, weed out false positives, and prioritize based on the actual risk to your organization. For vulnerabilities that no database knows about, a penetration test is a valuable addition – learn more under Penetration Testing. After scoping, you’ll receive a fixed-price quote within 24 hours (on business days); you can request it via our Pentest Quote page.