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.
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.
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.
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.
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.
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.
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:
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