Skip to content
CVE assignment documentation
Find file
Failed to load latest commit information. Typos
LICENSE Initial commit changes requested by solar


CVE assignment documentation - this document replaces

Please note that this document pertains to CVE's for issues found in Open Source programs, not closed source programs, if you need a CVE for a closed source program I suggest you go to Mitre directly.

Copyright: Red Hat 2015 Author: Kurt Seifried (

What is CVE?

A CVE is a common name for a single security vulnerability so that we can identify and talk about issues sanely (e.g. "that OpenSSL vulnerability, from like 2009, the DoS one" vs. "CVE-2009-3555"). CVE allows multiple vendors, products, and customers to properly track security vulnerabilities and make sure they are dealt with.

The CVE database is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration."

Why should I get a CVE for my security issue?

Because it makes it much easier to track, discuss and otherwise handle security issues for everyone. Upstream vendors, downstream vendors, security tracking firms, customers, security products, etc. all increasingly rely upon CVE to identify issues clearly.

Why should I get my CVE before going public?

Getting the CVE before public release makes tracking the issue much easier, if you release the issue and then get a CVE for it everyone will have to update their information (considering how many organizations consume security reports, this is a lot of effort). Also if other similar issues are released it makes tracking much easier rather than playing the "well it sounds like this one but maybe it's that other one?"

How do I request a CVE?

There are 4 main ways to request a CVE:

  1. In advance privately from
  2. In advance privately from the list
  3. In advance privately from Mitre
  4. Publicly on the list

You can request a CVE from, this is generally the quickest way (we have a team of people that can assign CVE's). You'll need to include some basic information such as the title, type of vulnerability and so on so that we can make sure the assignment is done correctly. If we have any questions about the assignment we will ask, so don't worry, if something is missing or unclear we'll ask. The GPG key is available here

Please note that although there is no strict limit on the time from which you request a CVE to the time you release the information we do generally ask that you take no more than 30 days to release the information.

You can request a CVE from the list. This will actually be fulfilled by Red Hat (the same people doing basically) and has the same basic process. Carefully read the entire page and confirm that you have done so and that you accept its terms by including the magic characters stated there in the Subject line otherwise your email will be rejected.

Your primary intent of bringing the issue to the distros list must be to notify the various BSD and Linux vendors ( who can then start working on their updates as well. Please note: emailing the distros@ list starts a 2 week embargo process so if you cannot address the issue and go public in 2 weeks or less I suggest either holding off on the CVE request, or using directly.

If for some reason you do not feel comfortable asking Red Hat or the distros@ list for the CVE you can request one directly from Mitre by emailing Please note that the Mitre team handles literally thousands of CVE requests a year so it may take some time for a response.

Finally if you have a public issue, or find an issue that is already public please ask for a CVE on the mailing list, this will also notify the community of the issue. A classic example of this is the "CVE Request: Linux kernel crypto api unprivileged arbitrary module load" which was originally found in 2013, but not made widely known as a security issue until 2015. Sooner is always better for security issues.

How to write a CVE request:

There is not much information that is required:

  1. Software name and optionally vendor name
  2. Link to the software web site (so we can download to confirm it, etc.)
  3. Type of vulnerability or attack outcome
  4. A description of the affected code (e.g. the function name, the vulnerable web page, link to the affected code, a bug entry, etc.)
  5. Ideally some information about affected versions (especially if the issue has already been corrected in a release)
  6. Whether or not a CVE has previously been requested anywhere (e.g. if you emailed someone and they never got back to you), this is to prevent duplicate assignments.

Examples of good and bad requests

Good requests:

Bad request: - this one is a bad request because the affected product name was mixed up (Ruby-on-rails/Ruby)

Why doesn't my CVE show up in the database?

The two main CVE databases:

Rely on Mitre for entries to be created and added. Mitre does not add CVE text until they have researched the issue and written it up. This means that in a given year Mitre has approximately 8,000 to 10,000 issues in their database that need research and publishing, so there is an obvious delay, especially for issues that are not as significant/important.

Why was the CVE assigned days/weeks/months before going public?

Mitre has a "Date Entry Created" field in their database, this is the date the CVE was either assigned by Mitre to a specific issue, or the date that CVE was given by Mitre to another organization (such as Red Hat) for future use. For example CVE-2015-0201 through CVE-2015-0300 were assigned on November 14, 2014 to Red Hat, as of late January 2015 Red Hat has only used approximately half of these. For more information on this and the other fields please see

Something went wrong with that request. Please try again.