Whose CVSS score is it anyways?
Vulnerabilities have scores. Higher the score, the worse the vulnerability. The real fun begins when the scores do not match across scoring authorities...

Ah, to be a cybersecurity professional! You get to do such riveting tasks, such as...
<glances at notes>
Uh... figuring out what the CVSS score is for a given CVE?
Wat...
Okay, back it up! No, further! There, good. So!
CVE stands for Common Vulnerabilities and Exposures. Basically a bunch of people got together and said “hey wouldn’t it be great is we had a common, standardised system to see just how bad software bugs are?” And the CVE was born. US federal departments, European Union bodies, and a bunch of companies all jumped on board and said “yeah that sounds like a good idea, we should have an open register so you can look up stuff!”
CVSS is the thing that they use to put a number to it: Common Vulnerability Scoring System. It takes into account a whole lot of different aspects, like how far do you need to be the system to exploit it: over the internet, on another computer in the local network, or you need to be at the computer itself? Or how complex it is to trigger it: do you need the memory layout to be some very specific state and even then it depends on a race condition which may or may not happen? Or can you send a simple request somewhere and it would happen every time? The full list of these is on the Wikipedia page. There are calculators for this as well, like the one on the NIST site.
Further complicating things is that there are different versions of the scoring system. v3 is being widely used, while v4 is just starting out.
As an example, let’s talk about CVE-2023-43804. Its base vector is this fantastic, absolutely human readable wonder:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Breaking it into parts:
- AV:N – attack vector: network, anyone, from anywhere can trigger it
- AC:L – attack complexity: low, most folks will be able to trigger it, it’s simple to do
- PR:L – privileges required: low, usually means random unauthenticated users can trigger it
- UI:N – user interaction: none, once request is sent, there’s nothing further to do
- S:U – scope: unchanged, the vulnerability will only cause havoc in the same component that the vulnerability is in
- C:H – confidentiality impact: high, which means total loss of confidentiality. All data the attacker wants will be supplied
- I:H – integrity impact: high, which means total loss of integrity, no protections left
- A:N – availiability impact: none. At least the system isn’t going to go down
In short: this is Bad™, and as such this CVE receives a score of 8.1. That’s high.
Tiers of Bad™ness
CVEs are sorted into four (five) houses in v3 and v4:
cve rating | score band | notes |
---|---|---|
critical | 9.0 – 10.0 | fix these immediately |
high | 7.0 – 8.9 | important, still fix these |
medium | 4.0 – 6.9 | when you have time, you should prioritize it |
low | 0.1 – 3.9 | if you’re bored |
none / unspecified | 0.0 | why are you spending time on this? |
There’s not much more to it, different companies treat their secure development differently. Some require software to not be released as long as there are critical and high vulnerabilities found in the software, but may employ exception strategies if vulnerabilities are in dependencies. It’s complex.
So what’s the issue?
Given all of the above, it stands to reason that a CVE is going to get a single score. Because it’s common. Standardised.
And then you have situations like CVE-2023-43804, and you want to figure out its score and tier. There are a lot of different listings you can look at: most vendors that provide security critical software, like operating systems, would have their own directory, as will the NIST, as wil security research companies.
In this particular case, on the NIST listing, this has a score of 8.1 / high. That listing also says that GitHub is a CNA (CVE Numbering Authority), and their score of the same CVE is 5.9 / medium. https://nvd.nist.gov/vuln/detail/cve-2023-43804
RedHat agrees with NIST’s GitHub score, and says it’s a 5.9 / medium. https://access.redhat.com/security/cve/cve-2023-43804.
Docker Scout says that NIST says it’s 5.9 / medium, contradicting NIST’s own score, and says GitHub scored it as a 7.4 / medium. https://scout.docker.com/vulnerabilities/id/CVE-2023-43804.
GitHub themselves score it as a 7.4 / medium. https://github.com/advisories/GHSA-v845-jxx5-vc9f.
Which is it? Is it 5.9, or 7.4, or 8.1? Because I have no idea...
Photo by Dan Meyers on Unsplash