CVSS
📌 Article pinned by VulDB Support Team
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 CVSSv2, CVSSv3, and CVSSv4 as well. Whenever the generic term CVSS is used in our service, all generations of CVSS are meant.
CVSSv4 | Documentation | Calculator |
---|---|---|
CVSSv3 | Documentation | Calculator |
CVSSv2 | Documentation | Calculator |
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 (called CVSS-B in CVSSv4) which analyses the structure of the vulnerability only. The extended score is the Temp Score (called CVSS-BT in CVSSv4), which introduces time-based aspects like exploit availability. VulDB supports both of these score types for all available CVSS generations.
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 and commit. 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.
Web Browser Memory Corruption
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.
Web Application Unrestricted Upload
A similar discussion is possible when we talk about unrestricted file uploads as CWE-434 on web applications. The attacker will earn the permissions of the web server (for example PHP) which should not be root or administrator nowadays by default. This is why the impact level of such vulnerabilities are rated as C:L/I:L/A:L
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.
"Privilege 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.
Re-Scoring Process and Possibilities
CVSS scoring allows some individual interpretation which might differ from analyst to analyst. To guarantee a steady and reliable scoring we use a well-defined guideline for our own risk scoring.
It is not unusual that we use slightly different scoring definitions than other sources (e.g. NVD or vendors). If our scoring is based on wrong assumptions (e.g. authentication requirements), please elaborate so we may update the values if necessary. Such changes must happen within the boundaries of our internal risk scoring guidelines and cannot be outside of these to reflect individual interpretations by 3rd parties.
If you are the researcher that found the vulnerability, you may change the researcher score of an entry. The same is possible if you are the vendor that develops and maintains the product. These additional scores are shown in the service and are able to impact the Meta Scores as well (if available).
We do not provide a public scoring possibility if you are none of the supported sources. However, in this case maybe you want to share your personal assessment as a public comment of the vulnerability entry. This might help others to understand your personal view as well.
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.
Alternative Risk Metrics
We also provide a wide variety of other risk metrics.
Updated: 09/03/2024 by VulDB Documentation Team