In light of COVID-19 precaution measures, we remind that all ImmuniWeb products can be easily configured and safely paid online without any human contact or paperwork.

Total Tests:
This Week:
Today:
Stay in Touch

Weekly newsletter on AI, Application Security & Cybercrime


Your data will stay confidential Private and Confidential

What’s new in CVSSv3 vulnerability scoring system?

Monday, September 21, 2015 By Read Time: 2 min.

In June 2015 The Forum of Incident Response and Security Teams (FIRST) has announced the availability of version 3 of the Common Vulnerability Scoring System (CVSS). Let's see the changes it brings in comparison to CVSSv2.


Since years High-Tech Bridge has been using CVSSv2 vulnerability scoring system both for our services and security research. In June 2015 The Forum of Incident Response and Security Teams (FIRST) has announced the availability of version 3 of the Common Vulnerability Scoring System (CVSS).

We have recently migrated ImmuniWeb® web application security testing platform as well as our security advisories to CVSSv3, and we are pretty much happy with the changes came up with the third version. Let’s have a look what’s new it brings to the security industry.

First of all, the format of CVSS score is now slightly different. Let’s take a simple SQL injection vulnerability as an example. CVSSv2 base score has the following format:


7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)

While the CVSSv3 base score will look like this:


8.8 [CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H]

One of the biggest and most significant changes are four new metrics in the Base Score:


Attack Complexity (AC) – is aimed to replace less comprehensible “Access Complexity” of the second version of CVSS. Attack Complexity metric can have only values now: “High”(H) and “Low” (L), previously available “Medium” (M) is eradiated. On one hand it’s definitely a good change, as in the past a lot of vendors were underscoring the final CVSS score by using overstated and pretty subjective Medium value. Now, it’s much easier to choose between two possible values. However, it provides a little bit less flexibility for some cases, as even pretty common XSS vulnerabilities may have low, medium and high complexity of exploitation.

Privileges Required (PR) – replaces the “Authentication” (Au) metrics from the second version of the standard. It has a little bit less comprehensive, but more adopted to a modern environment, possible values: “None” (N), “Low” (L) and “High” (H). Their meanings and usages are pretty obvious.

User Interaction (UI) – is a completely new and very useful metrics, especially for certain classes of web vulnerabilities, such as XSS and CSRF. It compensates a missing Medium value in Attack Complexity metrics. The values are pretty straightforward: “None” (N) and “Required” (R).

Scope (S) – is also a novation of CVSSv3 that can have “Unchanged” (U) and “Changed” (C) values. The second value shall be attributed if the exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component. For example it’s the case for a vulnerability allowing uploading a web shell on the server and compromising the entire web server and its environment.

All impact metrics now also have slightly different values: None(N), Low(L) and High(H). However, they are very similar to the CVSSv2 ones: None (N), Partial (P) and Complete(C).

So far, the new version is much more adopted for assessing web vulnerabilities, and we strongly recommend using it. CVSSv3 calculator is available here.


High-Tech Bridge Security Research Team regularly writes about web and mobile application security, privacy, Machine Learning and AI.

User Comments
Add Comment
2 responses to "What’s new in CVSSv3 vulnerability scoring system?"
Scooter Thetroll 2015-09-23 15:47:29 UTC Comment this
There is no impact to availability in SQL injection per the CVSS v3 Specification Guide, "The Availability metric speaks to the performance and operation of the service itself – not the availability of the data."
High-Tech Bridge Security Research 2015-09-23 18:12:34 UTC Comment this
In CVSSv3 we have a new Scope metric, which represents impact on vulnerable component, e.g. resource. In our case, SQL injection impacts the vulnerable web application and not the web server or database. That is why we calculate impact metrics regarding this component or resource. We can use SQL injection to make this resource inaccessible, that is why Availability Impact metric is set.

In the comment you reference a completely different scenario, where the resource is a network service that can be used to alter certain files, but do not disrupt the service itself.

You can refer to example No 19 (https://www.first.org/cvss/example s) – CSRF in SearchBlox. Here Availability Impact metric is set, because the Scope metric is not changed and the vulnerability can be used to render the website inaccessible.
↑ Back to Top

Ask a Question