How to reserve a CVE: From vulnerability discovery to disclosure

What is a CVE?

A CVE, meaning Common Vulnerabilities and Exposure, is a publicly reported vulnerability in software products. Vulnerabilities are assigned CVE IDs to ensure clarity when discussing vulnerabilities in software products. Otherwise, it can be difficult to correlate reports of a single vulnerability since different organizations will assign them different names, and the same product may have multiple instances of the same vulnerability (buffer overflows, remote code execution and so on).

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

The CVE reservation process

The researcher that discovers a vulnerability has the ability to reserve a CVE. If you believe that you’ve discovered a new vulnerability, you can reserve a CVE through the following process.

1. Verify that a CVE ID is needed

A CVE is appropriate if a vulnerability has been detected in software. To be considered a vulnerability, some exploitable code must pose a threat to the confidentiality, integrity or availability of the software or the data that it processes. Additionally, to fix this issue, some modification in the code or specifications is required.

If a CVE is appropriate, the next step is verifying that one does not already exist for the CVE in question. This can be accomplished via a keyword search on the CVE website.

2. Contact the affected vendor

Working with the affected vendor is highly recommended as part of the vulnerability disclosure process. Irresponsible disclosure of a vulnerability without a “good faith” effort to contact the vendor and allow a patch to be released places users of the affected process at risk.

MITRE recommends the following steps for working with the vendor:

1. Contact the vendor’s security contact (if available) or technical support. Provide a full description of the vulnerability in question, steps for exploitation, and proof of concept (if available). Allow five business days for the vendor to respond. An auto-reply message does not count as a response.
2. Work with the vendor to correct the issue. This may include additional explanations, further analysis of the vulnerability, patch testing and accuracy checks of both your and the vendor’s advisories.
3. If the five-day window expires with no response, reach out to a third-party “coordinator”, such as CERT/CC. These coordinators may have connections that improve their ability to receive a response.
4. If the vendor and an established response team (such as CERT/CC) will not issue an advisory, publish to a public forum that allows community validation. Options include the Bugtraq and Full-Disclosure mailing lists or Exploit-DB and Packet Storm sites.

Public vulnerability disclosures — especially ones with details of the vulnerability and its disclosure — should not be released until a patch has been made available and system administrators have an opportunity to apply it. If a vendor is moving too slowly or resisting patching, reach out to CERT/CC or other coordinators.

3. Work with a CNA

A CVE Numbering Authority (CNA) is an organization that can assign CVE numbers. To reserve a CVE number, reach out to one of the following (in order of preference):

• Vendor CNA: Some software vendors act as CNAs for their own software. If a vulnerability is discovered in one of these vendors’ products, reach out to their CNA contact.
• Third-party coordinators or email lists: If no vendor CNA is available, reach out to a CVE coordinator (like CERT/CC) or post on a mailing list like Bugtraq or OSS Security. After the vulnerability has been validated, it will be assigned a CVE.
• Root CNAs: If no CVE is assigned after following the methods above, reach out to one of the CVE Program Root CNAs to request a CVE. This can be accomplished via the online CVE Request Form.

To determine the appropriate CNA to contact and the organization’s POC for CNAs, visit MITRE’s list of CNAs.

After requesting a CVE, you should be contacted by the CNA. Respond to any requests for clarification or additional detail. At the end of the process, a CVE number should either be assigned or the request will be officially rejected (with a rationale). If a CVE is assigned, it will be officially listed as “Reserved” until step 5 is completed.

4. Share the CVE with others

If a CVE has been assigned, it should be shared with the vendor and any other parties involved in the process. This helps to ensure that multiple CVEs are not assigned by different CNAs for the same vulnerability.

5. Public vulnerability disclosure

When appropriate, make a public disclosure of the vulnerability. In the announcement, clearly associate all assigned CVEs with the associated vulnerability. This is especially important if multiple CVEs are included in a single disclosure as system administrators need to know where on the CVE List to go for more information on a particular issue.

After publishing a disclosure, notify the CVE team via the CVE Request form (“Notify CVE about a publication” option). This notifies the CVE team to change the CVE record from “Reserved” to including information about the vulnerability on the page.

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

Responsible vulnerability management

If you have discovered a legitimate vulnerability, you deserve credit for doing so. Registering for a CVE provides official recognition of your discovery.

It is also important to ensure that vulnerabilities are corrected by the vendor; however, it is vital to do so responsibly. If a vendor ignores attempts at contact or refuses to issue a patch, always go through the proper channels (contacting CERT/CC or similar) before publicly exposing the vulnerability. While “name and shame” may be the only way to push some vendors into disclosure and issuing patches, doing so prematurely without exploring the options doesn’t just hurt the vendor. It also places any users of the vulnerable software at risk of exploitation with no ability to fix the issue.

Sources

Search CVE List, CVE

Submit a CVE Request, CVE

Request CVE IDs, CVE