We were once newcomers to the security research field and one of the most annoying problems we ran across was how to get a CVE published. After all, what good is it to find a juicy vulnerability if you can’t get the word out to others? So, as a resource to help our fellow researchers, we decided to put together a CVE publishing guide based on our experience, and honestly a lot of good old trial and error. This guide will, hopefully, let you skip the headaches and guesswork that we endured learning this process when you try to get a CVE published.
Step 1: Making Sure the Vulnerability is New
Congrats! After much hard work, you found a 0-day! Now, before you do anything, make sure that the vulnerability hasn’t been spotted and reported by anyone else. To do this you absolutely need to check the MITRE database. it is also advisable to explore whether the vulnerability was previously discovered through searches on Google, Github, ExploitDB, PacketStorm, and other exploit repositories on the Internet.
Step 2: Contacting the Product Owner
Since your vulnerability is new, your next step is to attempt to contact the vendor/product owner and responsibly disclose the issue. At this point, one of two things will take place. Either the vendor/product owner will respond and work with you to resolve the issue or you will hear nothing but crickets in response to your attempts to communicate.
Here’s the important part, make sure you take screenshots, save all emails associated with this project and do everything you can to document that you attempted to contact the application owner. Note the date on your calendar since this is when the clock starts ticking. Use every possible (feasible) method you can leverage to contact the vendor, including e-mail, phone, and/or platform messaging. Tagging the company on social media sites and asking to be put in touch with someone on their security team is also a great way to get in touch with the appropriate security team.
Step 3: Coordinating With a Responsive Vendor
Now, let’s assume the vendor quickly responded to your notification, wants to work on mitigating the vulnerability and issue a patch. The key here is to aim for coordinated disclosure.
In an ideal situation, you will release the vulnerability details after the vendor has released a patch. MITRE has some documentation on how to progress your CVE to disclosure that is very helpful to use when working with a cooperative vendor. Ensure that you and the vendor agree on what is being disclosed and how. This will vary between vendors and also based on the CVE in question.
Step 4: The Sound of Silence
For many reasons, sometimes a vendor will ghost you. If this is the case (and it frequently is) this is what we’ve found to be the best approach:
Disclosure is a gray area with no defined rules, but most researchers wait for 30, 60, 90, or even up to 120 days after notifying or attempting to notify the vendor before publicly disclosing the vulnerability. While you are waiting, go to the MITRE website and fill out the CVE request form. This process is going to be done on a case-by-case basis (ex. if the company/owner is a CVE Numbering Authority, also known as a CNA).
If you don’t see the vendor in the CNA list, fill out the form found here. From personal experience, the process to get the CVE entry accepted has taken roughly 30 days on average, so we like to submit this once we find the vulnerability. Once you get a CVE ID (they will notify you by email), you’ll notice that it’s in a RESERVED state. This means that your CVE has been accepted by MITRE but not yet published. This is MITRE acknowledging that you have something valid and a CVE number is assigned to it, but they are awaiting disclosure.
The Downside of Disclosure
While finding and revealing vulnerabilities is extremely beneficial to the industry, there are a few points to keep in mind. Once a vulnerability is disclosed, threat actors are likely to act upon the issue, so it is imperative that you do not publish without taking every opportunity to contact the vendor and follow responsible disclosure protocols. If you are involved with a bug bounty program operated by the vendor operates then, unfortunately, their disclosure policies may prevent you from disclosing your finding.
Step 6: The Wait
Now while you’re waiting to hear back from MITRE, it’s generally a good idea to keep trying to contact the application owner/developer at least every 30 days. Once you have waited the length of time you are comfortable with, or to whatever time frame the application owner and you agreed upon, it’s time to publish!
This is the best way that we have found to accomplish publishing your discovery:
- Send POC/exploit to PacketStorm Security/CX Security. A good format for the header is what Exploit-DB shows here. Make sure that you include the RESERVED CVE-ID that you got from MITRE when you submit to these two websites.
- Once the exploits are published, send the links to MITRE by replying to the email that they sent you with a link to the published POC/Exploit.
- MITRE typically has a quick turnaround for this (one day or so). Sometimes it will email you with an update, sometimes the organization does not. The best thing to do is to check the original CVE link that you were sent and see if it changes from RESERVED and shows the details of the CVE.
- Congrats! You have a published CVE!
- Optional: You can try to send your exploit/POC to exploit-db. They typically won’t respond with an update on whether they decide to publish or not, but if not, try and try again!
Bonus Pro Tip
A number of our fellow researchers had some issues with responsiveness from MITRE and gave us some advice to share:
If MITRE doesn’t respond to your email after months, it’s enough to open a new request not as a “CVE Request” but as “other”, specifying you are waiting for such a long time… after doing this, they should reply to you after 24 hours with CVE IDs.
Happy Hunting!
Trustwave SpiderLabs maintains our own Responsible Disclosure program. The public policy is posted here: https://www.trustwave.com/en-us/legal-documents/trustwave-spiderlabs-vulnerability-disclosure-policy/
Additional Resources: https://cve.mitre.org/CVEIDsAndHowToGetThem.pdf
