Integrate vulnerability information from VulnDB in MISP

Extend MISP with modules

MISP, Malware Information Sharing Platform & Threat Sharing is a feature-rich platform for sharing threat intelligence information. You can extend MISP so that it integrates nicely with your own security solutions via the MISP module extensions. These MISP module extensions,, allow you to

  • extend the MISP threat intelligence sharing platform without altering the core;
  • connect and enrich the MISP information from other information providers;
  • get started quickly without a need to study the internals of MISP.

I previously contributed a MISP module to import malware analysis information from VMRay : Submit malware samples to VMRay via MISP.

Vulnerabilities in threat information

The fourth phase of the Cyber Kill Chain, exploitation, often (but not always) makes use of a vulnerability in a system.

Identified vulnerabilities receive a CVE number. CVE or Common Vulnerabilities and Exposures is a list of common identifiers for publicly known cyber security vulnerabilities. You can track these CVE numbers via the MISP attribute vulnerability.

You can enrich the information on a CVE via the default CVE MISP module (from CIRCL) with data available from

Next to the information from CIRCL, there are other information providers that can give more extensive information on a CVE number. One of these providers is VulnDB by Risk Based Security.

Important to note is that VulnDB not only gives you information based on a CVE identifier but also information on vulnerabilities that do not have a CVE. Additionally, the information that is provided by VulnDB based on a CVE gives you direct pointers to the mitigation measures and detection indicators.


VulnDB provides vulnerability intelligence via a web portal and via a RESTful API.

Although the web portal allows you to retrieve all details (ideal to get a first understanding on the scope of the vulnerability), the real power lies in the integration of the API data in your own ticketing system, GRC tools and threat information platform.

This is the information on vulnerabilities how it displayed in the VulnDB web interface. First you have an overview of all vulnerability records.

You can zoom in into a specific vulnerability and get CVSS and metrics information.

The detailed information contains data on the affected products and relevant vendor information.

The information that can be added to a MISP event based on a CVE identifier from VulnDB includes

  • External references
    • News articles
    • Vendor information
    • Exploit information
    • Mailing list posts
    • Blog posts
  • Products affected
  • CPE information
  • Dates when the vulnerability was reported, fixed or when an exploit was made available
  • Description of the vulnerability
  • Solution for the vulnerability
  • Classification of the vulnerability
  • CVSS scoring (from different sources)

The CPE information can be very valuable for large environments when it is tied to an inventory tool. CPE or Common Platform Enumeration allows you to identify what assets (OS, software packages, …) are subject to a given vulnerability.

I wrote a MISP module to integrate VulnDB with MISP via enrichment of a vulnerability attribute.

MISP module for VulnDB


A pull request for the VulnDB MISP module is pushed to the MISP modules repository. It requires at least two parameters

  • apikey : the API key;
  • apisecret : the API secret.

These two parameters allow you to connect to the VulnDB API via OAuth2.

There are a couple of -optional- parameter to tune the integration of the data. Note that by default these parameters are set to ‘False’, meaning that the information is included in the enrichment.

  • discard_dates : Include reporting the dates when the vulnerability was discovered, was reported to the vendor and when an exploit was made available;
  • discard_external_references : Include external references like news article, vendor information, exploitdb information; This information is added as ‘links’ to the MISP event;
  • discard_cvss : Include CVSS scoring;
  • discard_productinformation : Include information on which product this vulnerability applies;
  • discard_classification : Include the vulnerability classification reported by RBS;
  • discard_cpe : Include CPE information; This information as the ‘cpe’ attribute to MISP.

Flow of the module

The module takes as input the vulnerability attribute and can return the attributes text (description of the vulnerability, dates, product information, CVSS, classification), links (the external references) and CPE information.

Enriching CVE information in MISP

Access to the VulnDB information is done via the enrichment option of MISP modules for the attribute ‘vulnerability’.

When you have selected the CVE identifier to lookup within VulnDB you can add the different attributes to include in the MISP event.

Sharing of information from VulnDB

The information that you add to the MISP events and retrieved through enrichment from VulnDB is subject to a license agreement.

This is something that you have to take into account when adding extra attributes to an event. When you add new information coming from VulnDB to a MISP event you have to make sure that you only share this with the sharing group that is defined in your license agreement with VulnDB. In practice this often means your organization or team. You can easily enforce this when defining either a new sharing group that contains your internal teams or limit sharing within your organization.

Also see (Auto)set distribution level of imported attributes.

Integrating the information coming from VulnDB into your own tools will prove valuable but as this is not ‘public’ information you have to make sure that you stay compliant with the VulnDB license. Reach out to your contact within VulnDB / Risk Based Security if you have any doubts.

My experience is that RBS is open to find a workable solution that allows you to make use of the information for internal purposes and still comply with the license model. This is also important for historical information that you added to MISP events and how to deal with this information once your VulnDB license expires. When in doubt, contact the people from RBS.

Workflow VulnDB and MISP

  1. Your security team analyses a new malspam wave (for example a phishing e-mail containing a malicious file)
  2. A new MISP event is created, containing the initial indicators from the e-mail
  3. The malware attached is analysed in a sandbox (maybe via VMRay?)
  4. The malware attributes (indicators) are added to the MISP event
  5. The malware makes use of a known vulnerability (identified by CVE 123)
  6. Your team extends the MISP event with the information from VulnDB, based on the CVE number. This information contains the patch information and the software that is targeted by the malware (this is the CPE info)
  7. The MISP event now contains the CPE information and what needs to be done to be protected against the threat
  8. Your team now knows how the vulnerability gets exploited and what targets are in scope
  9. The MISP event is published and distributed within your organization
  10. The detection team knows what signatures to write to detect the threat
  11. New attack waves are detected via the sightings mechanism of MISP
  12. Your incident response team knows what information to look for during an investigation
  13. The patching team knows what assets are in scope and what assets need early patching


Sharing threat information is not only sharing indicators of compromise. It also includes sharing how these threat materializes and what vulnerability gets exploited. The information that is made available by VulnDB gives you detailed insight on the vulnerability and how it might affect your environment.

VulnDB is not free but you can request a demo and get product information via Risk Based Security.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.