Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

A Simple Guide to Getting CVEs Published

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

Latest SpiderLabs Blogs

Important Security Defenses to Help Your CISO Sleep at Night

This is Part 13 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies

Trustwave SpiderLabs’ 2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies report details the security issues facing public sector security teams as...

Read More

How to Create the Asset Inventory You Probably Don't Have

This is Part 12 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More