Common Vulnerability Scoring System
📌 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 form already.
"Partial and Temporary Crash" vs. "Full and Permanent Crash"
When it comes to denial of service attacks we distinguish between partial and temporary crashes vs. full and permanent crashes. For example, if an attack is able to render a web application useless but other services and remaining operating system work as intended, then the impact is limited which is shown as C:N/I:N/A:L. This is common for software which is running in user-space (e.g. web applications, client software). The same vector is also used if a full-system crash is only temporary (e.g. the system will reboot itself after the shutdown).
But if an attack is able to render the whole system useless then the extended impact vector C:N/I:N/A:H is used. In most cases a manual intervention is necessary to restore full system functionality. This is primarily used for attacks against operating systems. For example a Bluescreen of Death on Windows or a Kernel Panic on Linux.
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.
VulDB CVSS Scoring Guide
If something is not defined in the scoring guide but can be determined in the disclosure, then the proper value should be set. Otherwise unknown attributes shall be left empty and will be derived from historical data. A lower confidence level and a remark for this commit is set.
Scenario Definitions Influence Pre-Requisites
The defined values must be used. If an attribute is empty or multiple values are allowed, the best possible option shall be chosen. If an attack requires local access with AV:L, then we will almost always set PR:L, because most modern systems come with authentication requirements.
| Scenario | AV | AC | PR | UI | S | C | I | A | Explanation |
|---|---|---|---|---|---|---|---|---|---|
| Bruteforce Attack | | H | N | N | U | L | N | N | Set AC:H because it takes a lot of time. Almost always PR:N because the attack tries to identify login credentials. We do not classify the possible access attempt but the identification of login data as impact, which is why only confidentiality is affected with C:L. |
| Malicious File Opened by Victim | N | L | N | R | U | | | | Remote scenario with AV:N with UI:R for user interaction preferred, because file might be downloaded or sent via email. This is a default vector that might differ from other sources, because they focus on local attack scenarios. Pre-requisites not negotiable and impact level almost always L instead of H, because client software rarely runs with administrative privileges. |
| Attack against Client Software (e.g. web browser, mail client) | N | L | N | R | U | | | | Once again remote scenario with AV:N with UI:R for user interaction is preferred. This is a default vector that might differ from other sources. Pre-requisites not negotiable, because remote scenario is very usual and some kind of user interaction required. Impact level is almost always L instead of H, because client software rarely runs with administrative privileges. |
| Attack against Web Application (XSS and CSRF excluded) | N | L | | N | U | | | | Most attacks against web applications are AV:N for remote and have AC:L for a low attack complexity. Web applications rarely have administrative privileges, which is why impact is always L and never H. |
| Remote Code Execution without any Pre-Requisites | N | L | N | N | U | X | X | X | Remote attacks are always AV:N. Because the pre-requisites are the lowest, complexity is set to AC:L and no authentication required with PR:N. Impact level might differ. See impact severity definitions. |
| Remote Attack with Authentication Requirement | N | L | X | N | U | X | X | X | Remote attacks are always AV:N. Because some form of authentication is required PR needs to be set. In this scenario we almost never allow user interaction with UI:R, especially not if PR:H. |
| Server-Side Request Forgery | N | L | | | U | | | | Most attacks against servers are either remote with AV:N or within the same network with AV:A. Impact depends on possibilities. Some allow information gathering, like with port scanning which would affect confidentiality only. Others grant further access which would affect all three impact attributes the same way. |
| Malicious Activity by Local User or Local App | L | L | L | N | U | | | | Local apps are handled like local attackers, which sets AV:L. Whenever we define a local scenario, we also set PR:L, because nowadays almost non platform does not require some form of initial authentication. Impact level might differ. See impact severity definitions. |
| Attack with Physical Access Requirements | P | | | N | U | | | | Since CVSSv3 it is possible to set AV:P for physical attacks. In earlier versions, where this attribute was not available, we set AV:L which came closest. Attack complexity might vary. If additional activities like soldering is required, we increase to AC:H. An authentication is usually not required as PR:N as soon as an attacker gets physical access to a device. |
| Attack with Complex Dependency (e.g. Race Condition) | | H | | | | | | | Some attacks take a lot of understanding, time or effort which require an increased attack complexity as AC:H. Especially all kind of race condition attacks require AC:H due to complex timing behavior. |
Class Definitions Influence Impacts
The defined values must be used. If an attribute is empty or multiple values are allowed, the best possible option shall be chosen.
| Class | CWE (examples) | AV | AC | PR | UI | S | C | I | A | Explanation |
|---|---|---|---|---|---|---|---|---|---|---|
| Insufficient Authentication | 287, 288, 289, 290, 291, 294, 295, 297, 306, 384, 521, 798 | | | N | N | U | X | X | X | If administrative accounts are affected, then the impact level is H. Otherwise it is downgraded to L. In some rare cases a 2nd-step-authentication is affected which required a prior successful authentication. In this case PR:L would be set to reflect this pre-requisite. |
| Privilege Escalation | 264, 269, 284 | | | | | U | X | X | X | The impact depends on what privileges are earned by the attack. If non-root access is given, then the impact level is L. Otherwise it can be upgraded to H. Usually a scenario requires AV:L or PR:L to count as privilege escalation. See impact severity definitions. |
| Command Injection | 77, 78 | | | | N | U | X | X | X | The impact depends on what privileges are earned by the attack. If non-root access is given (e.g. execute simple directory listings), then the impact level is L. Otherwise it can be upgraded to H (e.g. changing the root password). |
| Memory Corruption | 119, 120, 121, 122, 134, 787 | | | | | U | X | X | X | Kernel impacts is H, otherwise just L. If no code execution possible, then only availability is affected and others are set to N. |
| File Manipulation | 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39 | | | | N | U | X | X | X | Attacks only affecting the file system will have an impact level of L which is almost always the case. |
| Denial of Service | 125, 369, 399, 400, 401, 404, 476, 789, 833, 834, 835, 911, 1333 | | | | | U | N | N | X | If Kernel or full system is impacted, then set to A:H. If only temporary and affecting sub-components, then set to A:L. |
| Cross Site Scripting | 79, 80, 81, 87 | N | | | R | U | N | L | N | This is a default vector that might differ from other sources. Impact is not negotiable. |
| Cross Site Request Forgery | 352 | N | L | N | R | U | N | L | N | We always use this default vector. Over the years most other sources aligned their vector to ours. |
| Session Fixation | 384 | N | L | N | R | U | L | L | L | We always use this default vector. An attacker has to enforce the session to the user which requires some form of interaction. |
| XML Attacks | 611, 776 | | L | | | U | L | L | L | Impact is never set to anything else. |
| SQL Injection | 89 | | | | N | U | L | L | L | Modern databases are not running with root privileges anymore, which is why impact is L. |
| Generic Injection | 74, 93, 1021 | | | | | U | X | L | X | It depends on the possibilities. Either all three impact vectors are set to L r just integrity. |
| Unrestricted File Upload | 434 | | | | N | U | L | L | L | File uploads in web applications almost never earn full system rights and the execution of these files on the client is a succeeding scenario not reflected in the primary CVSS vector. |
| Information Disclosure | 125, 200, 203, 255, 256, 260, 307, 310, 311, 312, 316, 317, 318, 326, 327, 330, 331, 332, 335, 338, 343, 425, 494, 532, 538, 552, 916 | | | | | U | L | N | N | This is a default vector that might differ from other sources. Impact is not negotiable, because nearly never all components of a system are affected (e.g. only CPU, memory, storage). |
| Eavesdropping in the Network | 319, 614, 1004 | N | H | N | N | U | L | N | N | If attack requires position between parties (e.g. within a network), then AC:H. If the position is within a network, then AV:N. Impact is not negotiable. We always use this default vector. |
| Weak Encryption | 261, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340 | | H | | N | U | L | N | N | Set always AC:H if there is some form of crypto established, because the attack takes usually some time. |
| Weak Certificate Handling | 295, 297, 298, 299 | N | H | N | N | U | N | L | N | Intercepting a certificate validation or forging a certificate is rather complex which is why AC:H. The impact is only affecting integrity in the first place which is a different reasoning than used by other sources. |
| Open Redirect | 601 | N | | | R | U | N | L | N | This is a default vector that might differ from other sources. Impact is not negotiable. |
| DLL Search Path | 426, 427, 428 | L | H | L | N | U | H | H | H | Other sources tend to use an entirely different vector. We always use this default vector. |
Impact Variants
Some vulnerability classes might have multiple default impact attributes. In these cases it is very hard without a deep technical analysis to determine the exact vector.
| Vulnerability Class | Scenario | C | I | A |
|---|---|---|---|---|
| Memory Corruption | Code Execution | X | X | X |
| Memory Corruption | Denial of Service | N | N | X |
| Directory Traversal | Full File Access | X | X | X |
| Directory Traversal | Read Only | X | N | N |
| Directory Traversal | Write and/or Delete Only | N | X | X |
| Null Pointer Dereference | Denial of Service | N | N | X |
| Null Pointer Dereference | Code Execution | X | X | X |
Impact Severity Definitions
If something is not affecting the full system, then the impact severity is always L. If the full system is affected or some part of the Kernel, then the impact severity is upgraded to H. This holds true for traditional operation systems but also for other platforms like smart phones or router with custom firmware.
If only confidentiality is affected, the impact level is always just C:L, no matter if it affects the operating system or Kernel. We never set C:H for confidentiality impacts because it is almost never the case that read access to the full system including all hardware components (CPU, memory, storage) is possible. In most cases just an isolated part is affected (e.g. database, local file storage). This is rather different than other sources approach CVSS impacts.
| Type | Products (examples) | Default Running as Root | Always Full System Compromise | Impact Level |
|---|---|---|---|---|
| Kernel | Linux, IBM AIX | yes | yes | H |
| Firmware | Apple iOS, Google Android | yes | yes | H |
| Router | Cisco Router, D-Link Router | yes | yes | H |
| Hardware | Arris Modem, Netgear Switch | yes | yes | H |
| Operating System | Microsoft Windows, Oracle Solaris | yes | maybe | H, L |
| Kernel Module | TCP/IP Stack, Samba | yes | maybe | H, L |
| Hardware Driver | GPU Driver, Network Interface Driver | yes | maybe | H, L |
| Firewall Device | F5 BIG-IP, CheckPoint Firewall-1 | yes | maybe | H, L |
| OS Virtualization | VMware, Oracle VirtualBox | yes | maybe | H, L |
| Software with Administrative Tasks | Antivirus Software, Desktop Firewall Software | yes | maybe | H, L |
| Database | MySQL, Oracle Database | no | no | L |
| Web Server | Apache HTTP Server, Microsoft IIS | no | no | L |
| Web Application | WordPress, Joomla | no | no | L |
| CMS Plugin | WP Funny Emoji Plugin | no | no | L |
| Web Browser | Google Chrome, Mozilla Firefox | no | no | L |
| Web Browser Extension | AdBlocker, Screenshot+ | no | no | L |
| Mail Client | Mozilla Thunderbird, Microsoft Office | no | no | L |
| Office Application | Microsoft Word, OpenOffice | no | no | L |
| Client Software | IrfanView, PuTTY | no | no | L |
| Software Package | gcc, vim | no | no | L |
| Smartphone App | WhatsApp App, Facebook App | no | no | L |
| Video Game | Cyberpunk 2077, Fortnite | no | no | L |
Forbidden Impact Attribute Combinations
There are some impact attributes which can never be combined because they are contradictory:
| Rule | Description | C | I | A | Correction | C | I | A |
|---|---|---|---|---|---|---|---|---|
| #1 | A vulnerability cannot have no impact. | N | N | N | Set at least one impact attribute to something other than N. | X | X | X |
| #2 | Almost never does confidentiality affect the whole system. | H | N | N | Set impact to C:L. | L | N | N |
| #3 | It is not possible to fully impact integrity of a system without also affecting availability in any way. | N | H | N | Set impact to I:L or both I:L and A:L. | N | L | L |
| #4 | It is not possible impact confidentiality and availability without impacting integrity as well. | X | N | X | Set all impact attributes to the same value. | X | X | X |
| #4 | It is not possible impact different attributes with different severities. (this is just one possible example) | H | L | N | Set all impact attributes to the same value. | X | X | X |
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 by VulDB Documentation Team