I recently checked the changelog of rundesk. One possible reason for upgrading was a CVE scored 'high'. This one:

https://nvd.nist.gov/vuln/detail/CVE-2022-45868

Total waste of everybody's time. You have to start h2 as server, instead of as dependency. You then have to start it with a command line parameter with a password, instead of specifying it in a config file. Both actions scream debug-configuration. If you do this, then... the password is readable on the command line.

That's the whole vulnerability. Analogy: if you leave a key on the table, people inside the same house can take it, and that's a vulnerability for the door.

So now h2 is 'vulnerable', every application needs to upgrade the dependency, and everybody needs to upgrade the application. What a total waste of time.

Very interesting read, written with understandable fury.

I find it concerning that software projects have to become CNAs to at least alleviate the harm of bogus CVEs.

There surely is some sort of CVE peer review? This should be possible for indefinitely long time after registering a CVE, because humans make mistakes.

So it shouldn't be needed to shy away from marking CVEs as invalid / rejected retroactively if appropriate.

It is understandable to err on the side of caution with vulnerability reports, but since reporting vulnerabilites has become an object of prestige, it seems needed to ramp up the scrutiny.

On the one hand it seems like, if you are reporting a security issue, you should presumably have some kind of PoC. On the other hand we’ve seen plenty of exploits that required chaining a half dozen not-obviously-exploitable issues to achieve a successful exploit. If someone at MITRE has to adjudicate these issues for every CVE in all possible programming languages for all possible exploits for all possible software… well that seems like a tough job anyway.

I think the people using the CVE database as some kind of official source of actual security issues, as opposed to reported potential issues, is the problem.

We should be defending the creators of our most important tools, like `curl`, from gratuitous time-wasters like these!

I'm glad the `curl` organization is a CMA now, though, maybe that will mitigate the issue.

Interesting that there seems to be two approaches to this - curl actually wants to carefully assign CVE only to security issues, Linux wants to defeat them with their own weapon by assigning CVE to every backported patch.

Sounds like the whole freegnix/nginx thing is farther reaching than just that project.

Many were questioning why he chose that particular hill to die on and I think article answers that question. It's a general problem and SOME CVE related hill needs to be chosen.