Researcher Reservation Guidelines

This document provides information on how to reserve a CVE ID(s) from the MITRE CNA of Last Resort (CNA-LR) before publicizing a new vulnerability so that CVE IDs can be included in the initial public announcement of the vulnerability and can be used to track vulnerabilities. Other CVE Numbering Authorities (CNAs) and other CNA-LRs have their own processes.

Some important things to note:

• The CVE request process reduces the amount of overlap with the work of other entities by identifying which organization(s) should be contacted first.
• The CVE request process is designed to ensure all vulnerability information included in CVE is publicly available. This reduces the risk of accidental disclosure of such information. Details provided in requests will not be released until those details have been made public.
• If a requester does not use and share CVE IDs properly, all CNAs and CNA-LRs reserve the right to refuse assigning CVE IDs to that requester in the future. Steps 2, 10, 11, and 12 in the list below provide details on proper use and sharing of CVE IDs.
• Anyone (researchers, vendors, or third-parties) can request a CVE ID be assigned to a vulnerability so long as they make the request using the proper channels.

The basic process for reserving a CVE ID from the MITRE CNA-LR is as follows:

1. Determine if a CVE ID is needed and appropriate. If yes,
2. Contact a vendor whose product is affected to disclose a vulnerability (coordinated disclosure).
3. Determine whether the request should be made to a vendor CNA. If no,
4. Determine whether the request should be made to a third-party coordinator CNA, or to a disclosure mailing list. If no,
5. Request a CVE ID as a last resort from the MITRE CNA-LR using the "CVE Request web form."
6. Provide the required information in the request.
7. Receive a confirmation email with a reference number and save it for your records.
8. Provide follow-up information as needed.
9. Receive a CVE ID (or an explanation if a CVE ID was not provided).
10. Share the CVE ID with all parties.
11. Include the CVE ID in the announcement of the vulnerability.
12. Notify the MITRE CNA-LR that the vulnerability has been made public using the CVE Request web form and selecting "Notify CVE about a Publication."

The CVE is then published by the MITRE CNA-LR Team, and will appear on the CVE List.

Also see:

Appendix A: Documents on Disclosure Practices
Appendix B: Determining if CVE IDs Are Needed
Appendix C: PGP Key

The steps above are detailed in the sections below.

1. Determine if a CVE ID is needed and appropriate

CVE IDs are currently only assigned to vulnerabilities that are going to be publicly announced.

1. Determine whether the problem you identified is a vulnerability.
   A vulnerability in the context of the CVE Program is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change, or specification deprecation to mitigate or address.
2. Ensure that the vulnerability for which you are seeking a CVE ID does not already have an assigned CVE ID by performing a keyword search of the CVE List on the CVE website.

2. Contact the affected product vendor directly

You should make a good faith effort to notify the affected vendor and work with them to ensure that a patch is available prior to publicly disclosing the vulnerability. Information is more accurate and complete when researchers and vendors work together. This practice also reduces the likelihood of a duplicate CVE ID being issued, which can happen when both a researcher and vendor request CVE IDs.

Without independent confirmation or vendor acknowledgment, it may not be possible to determine if the vulnerability is real, which could result in a request for a CVE ID being denied.

There are several documents that provide guidelines on disclosure. See Appendix A: Documents on Disclosure Practices for more details.

In general, you should do the following:

1. Find and notify the appropriate security contact for the vendor. If you cannot find a contact, try technical support.
2. Allow the vendor five business days to respond and acknowledge that they are aware of the problem. An "auto-reply" email or other computer-generated response does not represent vendor awareness.
   

   a) Work with the vendor to explain the problem, conduct further analysis if necessary, test any patches that the vendor proposes, and ensure the accuracy of both your, and the vendor's, advisory.

3. If, after five business days, the vendor is unresponsive, report the problem to a third-party "coordinator" such as CERT/CC. These coordinators may have contacts with the vendor, or they may lend credibility to your report.
4.  If an advisory will not be published by the vendor or an established response team (e.g., CERT/CC), you may choose to announce the vulnerability to a public forum that allows others to validate the claims. Currently, those forums include the Bugtraq and Full-Disclosure mailing lists, and sites such as exploit-db and Packet Storm.

When possible, do not announce a vulnerability until the vendor has provided a patch. This could take between one day and six months, depending on the vendor and the nature of the problem. If you believe that the issue is urgent and the vendor is not responding quickly enough, try using a coordinator as described in #4. Also, you should avoid releasing precise details of the vulnerability until system administrators have time to apply the patch.

3. Requests to a vendor CNA

Software vendors participating as CNAs assign CVE IDs for their own products. If the vulnerability is related to a CNA product, contact the appropriate CNA organization directly. If the request is accepted, the organization will assign a CVE ID for the issue and include it in its initial public announcement.

4. Requests to third-party coordinator CNAs or email lists

If a CVE ID cannot be requested through a CNA, consider contacting a third-party coordinator such as an emergency response or vulnerability analysis team (e.g., CERT/CC), especially when there are problems in contacting the affected vendor. If the request is accepted, that organization will work to have a CVE ID assigned to the issue. Or, you may post the information to mailing lists such as Bugtraq or oss-security and, if accepted, the issue will eventually be assigned a CVE ID by a CNA.

5. Requests to MITRE CNA of Last Resort (CNA-LR)

If you are unable to obtain a CVE ID via the methods cited above, you may request a CVE ID from the MITRE CNA-LR as a last resort using the CVE Request web form and selecting "Request a CVE ID" from the dropdown menu (view guidance). Complete the "Request a CVE ID" web form.

6. Information to provide in the request to the MITRE CNA-LR

The "Request a CVE ID" selection on the MITRE CNA-LR's CVE Request web form requires the following information:

• The type of request;
• The email address of the requester;
• The number of IDs being requested;
• The type of vulnerability for each CVE ID requested;
• The affected vendor for each vulnerability; and
• The affected product and version for each vulnerability (a generic name can be used if the vulnerability has not been made public).

The required information is the minimum information required to request a CVE ID. However, you can also provide optional information which can be used to provide additional detail for your CVE ID request and may be valuable to creating the CVE Record as well as for downstream consumers.

Optional information includes:

• Attack type;
• Impact;
• Affected component;
• Attack vector;
• Discoverer;
• References; and
• Any additional information.

7. Confirmation of request

Upon completion of the CVE Request web form, the requester will receive a confirmation email that the request was received and a reference number. If you need to communicate with the MITRE CNA-LR about this request, reply to the confirmation email without changing the subject line, as it contains the reference number associated with your request.

Continue to use email to provide additional information or to follow up on a request(s), as each new message is linked to the reference number for tracking purposes. If you do not seem to have received a confirmation email, please check your spam folder.

8. Follow-up information requests from MITRE CNA-LR Team

If the MITRE CNA-LR Team requires any additional clarification, they will contact the requester via email, referencing the confirmation number for the submitted CVE Request.

9. Receive a CVE ID (or rationale if not assigned)

Once there is enough information to confirm the vulnerability exists and that it affects a covered product, the CVE Team will reply to the requester with a CVE ID. The CVE ID is considered "RESERVED" at this stage. Descriptions with details of the vulnerability will only be added when the vulnerability is made public (see step 12).

If the vulnerability is not confirmed, or if it is not in a covered product, a CVE ID request may be rejected. In this case, the requester will receive a response from the MITRE CNA-LR notifying them of the decision.

10. Sharing the CVE ID with others

Once a CVE ID is obtained, provide it to all affected vendors and other parties (such as CERT/CC) with whom you are communicating. This makes it easier to share information about the vulnerability and reduces the risk that different parties may assign different CVE IDs to the same vulnerability.

11. Information to include in a vulnerability announcement

When publishing a vulnerability with an associated CVE ID, include the CVE ID in the announcement. Announcements containing multiple CVE IDs should delineate which CVE ID is associated with which vulnerability.

The following information may be contained in the vulnerability announcement:

• The CVE Program has assigned the ID CVE-YYYY-NNNN to this issue. This is a record on the CVE List, which standardizes names for security problems.
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-NNNN
• CVE ID: CVE-YYYY-NNNN

Some tips:

1. When announcing more than one CVE ID, associate each CVE ID with the vulnerability it is assigned to, so that people can easily identify which CVE ID is related to each issue. For example:

• CVE-yyyy-nnnn - buffer overflow in product
• CVE-yyyy-mmmm - format string

2. OSVDB offers additional suggestions about other content in the announcement:

• https://blog.osvdb.org/2013/01/15/researcher-security-advisory-writing-guidelines

12. Notify the MITRE CNA-LR of publication

After your announcement has been publicized, contact the MITRE CNA-LR via the CVE Request web form. Select "Notify CVE about a publication" and provide the following information:

• The CVE ID(s) assigned to the vulnerabilities being publicly announced.
• Links to the public forum(s) or advisories where the announcements can be found.
• (Optional) A description for each vulnerability to be used in the official CVE List.

Until this information is provided to the MITRE CNA-LR, only a reserved CVE Record may be recorded on the CVE website. No description or details of the vulnerability will be made available in the CVE Record until the vulnerability has been publicized.

When notified of a publication, the MITRE CNA-LR will then publish the CVE Record with a Description and References. This information will be made available on the CVE List.

The CVE information will also be updated in the U.S. National Vulnerability Database (NVD).

Appendix A: Documents on Disclosure Practices

The following documents describe processes and provide guidelines for coordinated vulnerability disclosure practices.

1. "Guidelines for Security Vulnerability Reporting and Response," Organization for Internet Safety. Version 2.0, 01 September 2004.
   https://www.oisafety.org/ │ http://www.symantec.com/security/OIS_Guidelines%20for%20responsible%20disclosure.pdf
2. "Responsible Vulnerability Disclosure Process," IETF draft document, Christey/Wysopal. February 2002.
   https://tools.ietf.org/html/draft-christey-wysopal-vuln-disclosure-00

Appendix B: Determining if CVE IDs Are Needed

There are several factors to consider to determine whether one or more vulnerabilities require a CVE ID when providing information to the MITRE CNA-LR:

A. Duplicates

Duplicates may be found by searching the CVE List on the CVE website and also by general web searches. Also, if a researcher previously contacted another organization on the CNA list about a vulnerability, a CVE ID assignment may already exist. The vulnerability should not be duplicated by the assignment of two CVE IDs.

B. Origination

CVE IDs are assigned to issues for which the primary method of addressing the vulnerability is for the vendor to take an action to remediate the vulnerability in their product. CVE IDs are not for cases in which the primary method of addressing the vulnerability is for an action to be taken by the operator of a single website or online service.

C. Establishing a policy violation

CVE IDs are needed when the vendor agrees that the observed product behavior violates a security policy, such as an unintended loss of confidentiality, integrity, or availability. CVE IDs are not for cases in which a reporter unilaterally believes that product hardening is desirable, such as a different approach to abuse prevention, or a different display of security-relevant data.

D. Establishing whether the vulnerabilities differ

In cases of multiple findings reported at the same time for a single product, separate CVE IDs are sometimes needed when there is a difference in the primary vulnerability types or affected versions.

E. Cross-vendor coordination

Separate CVE IDs are not assigned solely because vulnerable code is shipped in more than one product. Particularly in the case of open-source software, it is common for multiple vendors to use the same CVE ID in any scenario in which they have bundled, repackaged, or copied a piece of vulnerable code.

Appendix C: PGP Key

You may encrypt any post-web form communications using PGP or GnuPG (gpg), with the MITRE CNA-LR's PGP key, which can be downloaded from various PGP key servers.