The Common Vulnerability Scoring System (CVSS) is a vulnerability scoring framework that allows security practitioners to determine a vulnerability’s severity on a simple scale: low, medium, high, and critical. The score’s associated CVSS vector often provides much needed context to low-quality CVE descriptions.
Though the CVSS system has shortcomings, it is widely used throughout the security industry. This is due, in no small part, to the inclusion of a CVSS base score and vector in every entry of the National Vulnerability Database (NVD) maintained by NIST.
Due to their ready availability, CVSS scores and vectors are often used to drive vulnerability prioritization, and are incorporated into more advanced scoring schemes like EPSS, Qualys TruRisk, Tenable VPR, and SSVC (as the impact component).
So, while CVSS isn’t necessarily well loved (or even well understood), it’s a key driver of vulnerability management, as currently practiced by the security industry. However, scores in NVD aren’t always accurate. Incorrect scores impact immeasurable vulnerability management and remediation plans all over the world. Potentially resulting in many wasted hours diverting resources away from the vulnerabilities that should be prioritized.
As a quick example, consider CVE-2022-36446.
CVE-2022-36446 is a command injection vulnerability affecting Webmin. Webmin is no stranger to mass exploitation. It has an entry in the CISA Known Exploited Vulnerabilities (KEV) Catalog, and has been known to be exploited by botnets like Echobot and Sysrv.
CVE-2022-36466 has an associated Metasploit module and nice technical writeup by the vulnerability discoverer. At face value, this critical (this according to NIST) vulnerability appears to be an obvious one to prioritize for remediation.
However, NIST has assigned this CVE an incorrect CVSSv3 score. CVE-2022-36446 is not a critical vulnerability as it requires authentication. Correcting NIST’s CVSS vector drops the score from 9.8 (critical) to 7.2 (high). This drop in score makes CVE-2022-36446 significantly less of a priority.
Of course, that’s just one example from the 200,000 vulnerabilities in NVD. One off mistakes are bound to happen at that scale, and that’s understandable. More interesting to us is the potential for a large number of errors. The following is the NVD entry for CVE-2023-21557:
Above you can see two different CVSS scores for the same vulnerability. The primary score, calculated by NIST, is 9.1 (critical), and the secondary score, calculated by Microsoft, is 7.5 (high). No information is provided on why the scores differ, but NIST has chosen to assign itself as the primary and default score. Does NIST know better than Microsoft on this matter? Maybe. It seems unlikely, but without additional information it’s difficult to say.
This is not a unique situation. At the time of analysis, NVD contained 120,000 CVE with CVSSv3 scores.
- Of those, almost 25,000 (20%) had primary and secondary scores like the ones pictured above.
- 56% of that group had conflicting primary and secondary scores.
That very high conflict rate easily leads practitioners to question whether to trust the primary or secondary source. Primary, based on the name, certainly sounds more authoritative. But it turns out, NIST almost always assigns itself as the primary source. Of the 14 total primary sources found in the 120,000 CVE with CVSSv3 scores, NIST was listed as the primary source 116,169 times (97%).
Primary CVSS Source for CVE with CVSSv3 Scores
Undoubtedly, NIST has expertise in vulnerability scoring, but claiming the overwhelming majority of primary scores, even in the presence of other conflicting secondary scores, does make us wonder which score is more likely to be accurate.
Is the NIST generated score really the correct one to use 97% of the time?
Or might the score generated by the organizations in charge of the vulnerable software be more reliable?
To answer this, we dug a little deeper. Some vulnerabilities have elements of their CVSSv3 vector that must be set to specific values. For example, both XSS and CSRF vulnerabilities always require user interaction. Therefore, the CVSSv3 vector for these vulnerabilities must always contain UI:R (user interaction required).
To determine if a CVE is a CSRF or XSS vulnerability, we extracted the vulnerabilities’ CWE-ID from NVD.
Of the 120,000 CVE entries with CVSSv3 scores, we found 12,969 vulnerabilities had been assigned an XSS CWE by the primary source and 2,091 vulnerabilities were assigned XSS CWE by a secondary source. The primary source failed to use UI:R for XSS vulnerabilities 111 times, a 0.86% error rate. Whereas the secondary sources failed to use UI:R 346 times, a 16.54% error rate.
CSRF was less severe. The primary source only failed to use UI:R for 59 out of 2,548 (2.3%) CSRF vulnerabilities. The secondary source used the wrong UI for 27 out of 390 (6.9%)
The primary source (typically NIST) has the lower error rate, but it remains higher than you’d expect for a scoring element that can be checked and verified programmatically. The secondary sources error rate is quite bad at nearly 17%. In this case, it appears that NVD is the preferred source. Although that doesn’t necessarily translate to other vulnerability types.
The error rates were higher than we expected, which got us thinking, “Who is making these errors?” We mapped the errors to their sources and found 39 unique organizations contributed erroneous scores. The top five incorrect score sources can be found in the following graph:
Top Sources of XSS and CSRF CVE Incorrectly using CVSSv3 UI:N
CVSS scores are a driving force behind vulnerability management and remediation. Typically, the scores are sourced from NIST’s NVD. Therefore, the accuracy of the scores in NVD are an important factor in the database’s overall usefulness. There is reason to believe that there is a non-negligible error rate in NIST’s CVSS scoring which could have a negative impact on organizations that rely on NVD, directly or indirectly, for accurate information.
VulnCheck maintains a list of corrected CVSS scores. For more information, register for a VulnCheck account today.