Do all vulnerabilities have CVE?

CVE is a very popular word in the cyber security industry. If you take any penetration test or any vulnerability assessment report, you will find a bunch of CVEs for every asset. However, does this means that all the vulnerabilities have a CVE?

According to the vulnDB database of discovered vulnerabilities, at least 500 vulnerabilities discovered and published in 2020 do not have a CVE reference. These statistics prove that not all the vulnerabilities discovered in the world have a CVE. In addition, many other zero-day vulnerabilities are discovered and exploited every day without being published to the public.

Now, if you want to know more about why this problem exists and what makes it happen? Then please just keep reading.

What is a CVE and why is it important?

Before we dig deeper in explaining why this difference of CVE vs discovered vulnerabilities exists, I would like to explain a little bit what is a CVE and why is it that important in Cyber security industry. A CVE (Common Vulnerabilities and Exposures) represent an ID of a vulnerability in the MITRE database, which groups all the discovered and publicly published vulnerabilities.

CVE database references provide the organization a standardized identifier for a publicly published vulnerability. This standardization reduces drastically the time to access information about the same vulnerability over multiple platforms. In addition, this system gives vulnerability scanners vendors, the ability to test their tools and correctly see their coverage rate.

Number of affected CVE VS the actual vulnerabilities

I think one of the most logical question everyone would ask now is, why do we have a difference between the number of affected CVE and the actual number of vulnerabilities in the wild?

Actually, this difference comes from multiple factors in the industry of cyber security. The first one is that vulnerability discovery is not an exact science, I mean it can take 6 months to find one vulnerability for someone, and 1 week for another researcher. And, this has nothing to do with the researcher’s skills. So, the white hat hackers that contribute to the CVE database are not always lucky to find vulnerabilities before black hat hackers. Therefore, a vulnerability could be already discovered and exploited in the wild before white hat hackers finds it and send it to CVE database.

The second most popular problem that leads to this kind of difference is the delay of MITRE organization to add a new CVE to its system. Normally, the time needed to get a “RESERVED” CVE takes around 24h.

However, in some cases, this may take more than 2 months due to technical problems. In addition, to change the status of your RESERVED CVE to PUBLIC you should write a blog post describing your vulnerability and send it back to MITRE.

This long process contributes to making the difference between the number of published vulnerabilities and declared CVEs very high.

Are all CVEs checked before publish?

You need to differentiate between getting a CVE for the vulnerability you have discovered and getting that CVE publishes to the public. A Reserved CVE only means that you have reserved a place in the MITRE database, but nothing will show up for the public. Therefore, CVE database team does not check the validity of a vulnerability when they just reserve a CVE for it.

Then you will have to submit a blog post URL that explains the vulnerability to the CVE Database management team so that they change its status to Published. According, to CVE database statistics, they publish around 70 vulnerabilities every day. Therefore, if we say that only 50% of the submission that they receive is actually a false positive, then they will have to test 140 vulnerabilities every day.

Personally, I think that testing all the received submissions is not feasible, as the vulnerabilities submitted could affect any software in the world, and to test each one, they will need to put in place a test environment for every app. However, the submissions that affect a product that has a proper CAN, can be tested as the test environment could be already in place.

How to request a CVE Id?

If you have discovered a vulnerability in any product, you can easily submit it to the CVE database to get an ID. To do that, MITRE organization has put in place a process, to priorities the declaration of some vulnerabilities on others and make the process easier. Here are the steps you need to follow to correctly do that:

1. Go to https://cve.mitre.org/cve/request_id.html
2. Take a look at the CAN table below (in the same url), you may find that the vulnerable product you have found is managed by a known organization to the CVE database.
3. If so, then all you have to do is to look at the “CNA Contact Method” column and use those information to contact that organization and receive a CVE.
4. However, when the product you worked on is not supported by any declared CNA, then you should contact the Roots or CAN of Last Resort listed in the first table of the same URL.
5. Then you will receive a confirmation email that your submission is well performed (in case of using the MITRE standard form)
6. After 24h you get your CVE id with a reserved status and you will need to submit a blog post containing the details of the discovered vulnerability.

Is it possible to edit a CVE if a vulnerability report was wrong ?

It is always possible to edit a CVE by replying to the same email sent by the CVE team. However, to remove a CVE, no information has been published by MITRE that deals with this problem, and there is no way to contact them apart from the one for editing.