Every entry provides a CVSS score. CVSS stands for Common Vulnerability Scoring System and is an open standard for risk metrics of security issues. There are different versions of CVSS available. VulDB supports both releases CVSSv2 and CVSSv3 at the moment.

Generation of scores

The score is generated by separate values which are called vectors. Those vectors define the structure of the vulnerability. They rely on attack prerequisites and impact. The calculated score ranges between 0.0 and 10.0 whereas a high value declares a high risk.

Base and temp scores

The main score is the base score which analyses the structure of the vulnerability only. The extended score called temp score introduces time-based aspects like exploit and countermeasure availability. VulDB supports both of these score types.

Default values for unknown vectors

Our moderators classify every entry to generate a CVSS score as accurate as posible. If there is not enough information about the structure of the vulnerability, the team relies on other sources or default values. For example the Access Complexity (AC) of a persistent cross site scripting attack is usually L contrary to a reflective cross site scripting attack which is usually M. The confidence of this classification is stated for every entry. A high confidence indicates that all vector fields are known and defined properly.

Discrepancy to other sources

Other sources like NVD and IBM X-Force might use other vectors and calculate different scores. This might happen because further information about the technical structure of the vulnerability is available. Or because the moderators tend to use different assumptions to define vectors.

For example we are defining buffer overflow attacks against Microsoft Edge usually with the impact levels C:L/I:L/A:L. But if the browser is used by an administrative account the compromise might happen as C:H/I:H/A:H. Our moderators normally assume the worst which might happen in a real-world scenario. But because most administrators do not use Microsoft Edge to access insecure resources we tend to use the lower rating in this and similar cases. If the discrepancy is severe, there will be an explanation for this.

Wording makes the difference

Our moderation team is eager to understand a vulnerability structure as well as possible. The wording of an advisory can be hinting the technical structure and possibilities of an attack. For example the original vendor advisory by Microsoft for ID 155072 (CVE-2020-1028) states:

An attacker who successfully exploited the vulnerability could install programs; view, change, or delete data; or create new accounts with full user rights.
In our opinion this means that the attacker will earn the right of the user that is logged in right now. We assume that in modern Windows versions regular users are not working with full Admin privileges anymore. This is why we downgrade to C:L/I:L/A:L contrary to Microsoft which is declaring C:H/I:H/A:H.

Microsoft tends to use another wording whenever a successful exploitation grants full system rights, no matter which user is logged in. See ID 155162 (CVE-2020-1166) for example. The vendor advisory states:

An attacker could then run a specially crafted application that could exploit the vulnerability and take control over an affected system.
In such cases we raise to CIA to C:H/I:H/A:H. Which is sometimes similar like the self-assessment by Microsoft. Sometimes they still even just use C:L/I:L/A:L. Vendors tend to play around with CVSS vectors and scores to reach a desired level of impact. This is not a Microsoft specific issue. NVD tends to use the Microsoft score without further plausibility checks.

Support of external scores

The default scores used by VulDB for statistical are the scores defined by our vulnerability moderators. But the database does also support additional scores to allow to compare differences quite easily and quickly:

  • Vendor: Score published by the product owner, usually disclosed with an official advisory or a knowledge base article.
  • Researcher: Score published by the research who found and disclosed the vulnerability. This score is usually included within the initial disclosure of the issue.
  • MITRE NVD: Score published by MITRE within the National Vulnerability Database.
The VulDB vector and score is always created if there are any risk specific details about the vulnerabity available. The other vectors and scores are included if they are available. It is not uncommon that researcher and/or vendors do not publish their own vectors and scores. And vulnerabilities not included in NVD do not come with a score by MITRE. Furthermore old NVD entries do just support CVSSv2 scores and not CVSSv3 scores. VulDB does not complete or convert scores by 3rd parties.

Meta Scores

VulDB is providing the unique feature of a Meta Score. This score aggregates all available scores and generates an ultimate score. This makes it possible to combine the different scores from multiple sources.

Meta Index

Our unique C3BM Index (CVSSv3 Base Meta Index) cumulates the CVSSv3 Meta Base Scores of all entries over time. Comparing this index to the amount of disclosed vulnerabilities helps to pinpoint the most important events.

Interested in the pricing of exploits?

See the underground prices here!