CVSS
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 and the introduction of CVSSv4 is planned.
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 possible. 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.
We follow two basic principles to provide the best and most accurate experience for our customers:
- Remote First: If there are multiple scenarios possible via a remote or a local vector, we usually prefer the remote variant.
- Popular First: If the impact depends on the individual installation or user rights, we prefer the most common variant always leaning to the higher impact variant.
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.
"Full User Rights" vs. "Full System Rights"
For example the original vendor advisory by Microsoft for VDB-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 VDB-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.
"Privile Escalation" vs. "Remote Code Execution"
For example the original vendor advisory by Microsoft for VDB-223032 (CVE-2023-23397) uses the following wording:
| Title | Microsoft Outlook Elevation of Privilege Vulnerability |
|---|---|
| Impact | Elevation of Privilege |
Futher look at the CVSS Base vector by Microsoft reveals a contradiction. The Attack Vector is set to AV:N which equals remote. Because there is also no authentication required as indicated by PR:N we declare such as Remote Code Execution instead as Privilege Escalation.
Usually, a Privilege Escalation is either local and/or requires some form authentication. It is only possible to escalate privileges if some of them were granted in some reduced formalready.
Support of External Scores
The default scores used by VulDB for statistical purposes 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.
- NVD: Score published by the National Vulnerability Database.
- CNA: Score published by the responsible CVE Numbering Authority within the National Vulnerability Database.
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 number of disclosed vulnerabilities helps to pinpoint the most important events.