4 Steps to Getting CVEs Published

(Featuring research from Trustwave SpiderLabs researchers Adeeb Shah and Bobby Cooke)

One of the most frustrating problems as a newcomer to the security research field can be trying to navigate the process of getting common vulnerabilities and exposures (CVEs) published. After all, you just want to share your newly discovered vulnerability with the world!

Speaking on behalf of the industry, I think we’ve all had to face this difficult situation at some point in our careers. As a resource to help fellow researchers, I’ve put together the below CVE publishing guide based on my own personal experience (and, honestly, a lot of good old trial and error). This guide will, hopefully, help you avoid the headaches and guesswork and more easily get a CVE published.

Step One: Make Sure the Vulnerability is New

Congrats—after much hard work, you found a zero-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 and it is also advisable to explore whether the vulnerability was previously discovered using searches on Google, GitHub, ExploitDB, PacketStorm and other exploit repositories on the internet.

Step Two: Contacting the Vendor

Attempt to contact the vendor/product owner and responsibly disclose the issue. At this point, one of two things will happen: Either they’ll respond and work with you to resolve the issue or you will hear nothing but crickets in response to your attempts to communicate.

Use every available form of communication wherever possible—this includes snail mail, email, the website’s chat, social media and phone.

Here’s the important part, make sure you take screenshots and save all digital and physical records associated with your attempts to contact the vendor. Note the date on your calendar—this is when the clock starts ticking.

Step Three A: Coordinating with a Responsive Vendor

Let’s assume the vendor quickly responded to your notification and wants to work on mitigating the vulnerability and issuing a patch. The key, in this case, 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; this information is very helpful to use when working with a cooperative vendor.

Step Three B: The Sound of Silence and Potential Downsides of Disclosure

For many reasons—and more often than not—a vendor will ghost you. If this is the case, here’s what I’ve found to be the best approach: Disclosure is a grey area with no defined rules, but most researchers wait 30, 60, 90 or even up to 120 days after notifying or attempting to notify the vendor before publicly disclosing the vulnerability. However, before you take any further action, make sure you hire a lawyer if you’re working as an independent contractor or have your legal team in place and on alert if you’re working for a company.

Only after you’ve taken the steps to CYA should you go to the MITRE website and fill out the CVE request form. This process is going to differ on a case-by-case basis (for example, if the company/owner is a CVE Numbering Authority; 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 takes roughly 30 days, on average, so I like to submit this once the vulnerability is found. 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 submitted a valid vulnerability and that a CVE number has been 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. Another piece of information worth noting is that if you are involved with a bug bounty program operated by the vendor, unfortunately, their disclosure policies may prevent you from disclosing your finding.

Step Four: The Wait … Stay Vigilant!

While you’re waiting to hear back from MITRE, it’s important to know that your work is not yet done. The good news is that if you’ve gotten this far, you’re more than halfway there. The bad news is that you’ll also need to play the waiting game.

It’s generally a good idea to keep attempting contact with the application owner/developer at least every 30 days. Once you have waited the length of time you are comfortable with, or within whatever timeframe the application owner and you agreed upon, it’s time to publish!

This is the best way that I have found to accomplish publishing your discovery in three simple steps:

  1. Send POC/exploit to PacketStorm Security/CX Security. A good format for the header is shown here by Exploit-DB. Make sure that you include the RESERVED CVE-ID that you got from MITRE when you submit to these two websites.
  2. Send to MITRE. 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, MITRE will email you with an update; sometimes they won’t. The best thing to do is to check the original CVE link that you were sent and see if its status changes from ‘reserved’ and whether it shows the details of the CVE.
        • If months go by and MITRE doesn’t respond to your email, it’s probably time to open a new request—not as a ‘CVE Request’ but as ‘Other’; then, specify that you are waiting for a response to an earlier submission. After doing this, they should reply to you within 24 hours with CVE IDs.

Congrats! You have a published CVE!

Optionally, 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 it’s also worth a try. Happy Hunting!

Avatar photo

Karl Sigler

Karl Sigler is Threat Intelligence Manager at Trustwave where he is responsible for research and analysis of current vulnerabilities, malware and threat trends. Karl and his team run the email advisory service, serve as liaison with Microsoft MAPP program, and coordinate disclosures of discovered vulnerabilities. Most recently, Karl was one of the security researchers instrumental in identifying "Backoff" point of sale malware that affected more than 1000 retailers worldwide. Before joining Trustwave in 2013, Karl worked as the head of the IBM X-Force Education group for 12 years and has presented on topics like Intrusion Analysis and Penetration Testing to audiences in over 30 countries. In 2003 he released Knoppix-STD, the first Live LinuxCD dedicated to pen testing and forensics and a predecessor to distributions like BackTrack, Kali and Pentoo.

karl-sigler has 1 posts and counting.See all posts by karl-sigler