It was obvious already before that NVD really does not try very hard to actually understand or figure out the problem they grade. In this case it is quite impossible for me to understand how they could come up with this severity level. It’s like they saw “integer overflow” and figure that wow, yeah that is the most horrible flaw we can imagine, but clearly nobody at NVD engaged their brains nor looked at the “vulnerable” code or the patch that fixed the bug. Anyone that looks can see that this is not a security problem.
I agree with Daniel here that there is a problem, but I’m not sure I agree that NVD (or really, whoever the CVE Number Authority [CNA] for curl is) should be the party responsible for determining the CVSS score. It seems to me that apart from the cases where the CNA is the vendor the CNA will likely lack the context and understanding to appropriately score any reported issue. I’m not sure I’d agree that it should be any CNA’s job to verify all the CVSS scores. That would create an immense amount of work, that is better offloaded onto the reporter and the vendor.
I think there are a few issues at play here:
The first point, is usually not the case as I understand it. Each CVE by default needs some sort of acknowledgment of the issue existing from the vendor. Someone can’t just file for a CVE, saying there is an issue without some other evidence of it, there is some process for hostile and non-responsive vendors, but by default something from the vendor needs to indicate the issue exists. In this case the PR for the bug acknowledges the presence of an integer overflow which was probably enough for the CNA to go forward without further vendor involvement.
I feel like this is wrong, and that the vendor should get some involvement even when dealing with older bugs, especially those vendors like curl who have a history with dealing with CVEs in a non-hostile way. There is usually some communication during the CVE process so with older bugs like this case it should continue. Not sure what the official policy on this looks like, but it feels like the primary change that could be made.
The second point, the CVE’s CVSS score by the researcher is simply wrong[0]. I think this could have been solved with vendor involvement though so I won’t dwell much on this. Except to call out two common problems. One being artificially inflating CVSS scores by researchers; this is largely because of “clout” and because some bounties use it to determine payouts. The second issue being researchers who may understand how to find the bug but not how to score it’s impact just copying the CVSS from a seemingly similar report. That can work with like an XSS or something, but not so much with memory corruption issues. I feel like this is almost cultural, so many people see a critical CVE as some milestone.
Lastly, dependency on CVSS scores. I just don’t think CVSS accurately reflects the impact in many cases these days. So many companies treat CVEs and their CVSS score as the final word on prioritization though, and so when something come out with a high score, many places panic while actually meaningful issues go under-recognized. Not sure of a solution to this that can scale though.
Anyway, this is all going fairly off topic from the problem raised in the original post, but I wanted to write out some of my own thoughts on the CVE system and its issues.
[0] 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Curl itself is a local binary, there is a minimal network attack surface (processing server responses), this bug is all local, but the access vector is “network”. Confidentiality and Integrity are not impacted by the bug alone at all (CVSS has them as “high”). Any data curl might access you’d necessarily already need access to as the local user creating the request curl sends. Availability is also set to “high” but realistically its a self-dos at worst impacting only the one run of the program. T
This is why I’m glad to see some tools are starting to adopt the Exploit Prediction Scoring System (EPSS). It seems to do a little better job of helping defenders see how “bad” a vulnerability really is and prioritize more accurately.