CVE OpenSource Request HOWTO

By Kurt Seifried, Copyright Red Hat 2012

Version 0.5 June 18, 2012

  1. What is CVE?
  2. Why should you get a CVE(s) for security issue(s)?
  3. Requesting a CVE for an issue in an Open Source program
  4. How to make a public request
  5. How to make a semi-private request
  6. How to make a private (vendor) request
  7. How to make a private (Mitre) request
  8. How to write a CVE request
  9. Sourcing the information for a CVE request

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 you get a CVE(s) for security issue(s)?

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.

Requesting a CVE for an issue in an Open Source program:

There are several ways to make a request depending on what your requirements are:

Contact Who sees the info Embargo time Information required
Public Public none Detailed info
Semi-private Linux/BSD vendors Max 2 weeks Detailed info
Private (vendor) prearranged Limited (Red Hat) Max 30-60 days negotiated
Mitre Mitre negotiated negotiated

How to make a public request:

These are sent to ( They are completely public (anyone can sign up to the oss-security@ list, the archives are public). This is the best because everyone that cares to track CVE #'s will find out about it ASAP, also because it is a public request it is unlikely that anyone else will accidentally or otherwise request a CVE for the same issue.

Time line: I generally respond to these within one business day, this means you'll either get a CVE or a request for more information if the request is not properly formatted or is unclear/missing details/etc.

How to make a semi-private request:

If you have a semi-private issue (you want to notify vendors, but not the entire world, giving time for it to be fixed) the easiest way to do this is to email the list (

Please note that one of the list requirements is that issues be embargoed (kept private) for 2 weeks at most (e.g. 14 to 16 days depending on when during the week the email was sent). DO NOT SEND A REQUEST TO THIS LIST IF YOU NEED MORE THAN 2 WEEKS TO ADDRESS AND RELEASE THE ISSUE. The distros@ list is a private list consisting of security teams for Linux and BSD distributions. No archives of this list exist publicly at this time, although a time delayed archive may be created at some point (delayed at least 14-16 days so embargoed issues don't appear in the archives). The advantage of this list is it allows you to easily co-ordinate a public release with the projects most likely to ship your software (e.g. Linux and BSD vendors).

Time line: I generally respond to these within one business day, this means you'll either get a CVE or a request for more information if the request is not properly formatted or is unclear/missing details/etc.

How to make a private (vendor) request:

In order to serve the community better I've decided to allow private vendor requests that meet certain requirements and that are arranged in advance (since I need your PGP key, etc.). Email me at to set this up for your project.

How to make a private (Mitre) request:

If you are unwilling or unable to share any information regarding the CVE request than please go directly to Mitre at

Time line: I don't speak for Mitre (unknown).

How to write a CVE request:

This information is required for public requests to oss-security@ and private embargoed requests to distros@, and generally recommended for all other request types. More information up front means less problems down the road.

Information for CVE request that is REQUIRED:

  1. Email address of requester (so we can contact them)
  2. Software name and optionally vendor name
  3. At least one of (to determine if this a security issue):
  4. For Open Source at least one of:
  5. Request comes from security team of senior project member (a.k.a. "trust me, it's a problem")
  6. Affected version(s) (3.2.4, 3.x, current version, all current releases, something)
  7. If this has been previously requested (i.e. on OSS-Sec or to please inform me so we can avoid duplicates
  8. If multiple issues are listed please list affected versions for each issue and/or who reported them (so we can determine CVE split/merge status).

Information for CVE request, REQUESTED:

  1. More of the above information of course
  2. Software version(s) fixed (if available)
  3. Any additional information that helps determine the status of the flaws/fixes

Examples of CVE entries can be found at, examples of CVE requests can be found in the OSS-sec archives.

Sourcing the information for a CVE request:

Authoritative information is better. The upstream vendor advisories are ideal as they tend to be correct and sourcing them will generally not result in mistakes or overlap. This is especially important if the vendor has already requested or assigned a CVE to the issue they will likely place it within the security advisory they post online, checking this first will prevent multiple CVE's (the plural is also referred to as an infestation of CVE's) from being issued. Other good sources of information are the specific bugzilla entries, ChangeLog entries or code commits (ideally with identifying comments or other related meta-data). These will often give the original information and date of publication, however they tend not to be polished like a vendor advisory is. Although third party advisories and information can be used to source a CVE request this can lead to problems (lack of details, overlapping requests, etc.), so please, whenever possible include first hand sources.

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)