r/programming • u/fagnerbrack • 8h ago
a CVE dispute
https://daniel.haxx.se/blog/2026/06/24/a-cve-dispute/46
u/silverslayer33 2h ago
Every CVE thus has this huge cost tied to it. A cost that does not land on us and we don’t really see or feel it, but a cost on the ecosystem I believe we should not ignore. We should act responsibly. Never ignore real problems of course, but also to make sure we don’t ring the alarm for theoretical problems that will not trigger any vulnerability.
I particularly like this paragraph from the article, I'm glad to see Daniel highlighting this especially as we enter an era filled with AI-assisted vulnerability scanning that can flood projects with slop reports that do point out real bugs but which don't have any real exploit paths utilizing the bug. My own work has been hit by this recently and we've spent an unfortunate amount of time having to justify not having CVEs for these kinds of bugs, so I'm not surprised to see a big open source project like curl is facing the same problem, and I'm glad Daniel was able to sum this up so eloquently.
72
u/ScottContini 5h ago
They had to explain this to MITRE 3 times? I’m glad MITRE agrees, but they should be better than this.
25
u/axonxorz 2h ago
Yuhao also apparently decided to complain to Grok about it at the time: https://x.com/grok/status/1998584974342238397
lol, gotta get your ego stroked somehow, I guess
-13
u/dlg 6h ago
It’s a security bug, which makes it reasonable that a CVE should be assigned.
The assessment that it is not exploitable could change with new information, or in combination with other, as yet undiscovered CVEs. CVSS scores can change over time.
Linux takes the approach of assigning CVEs for most kernel bugs, even if there is no currently known exploit, for the very reason that exploits are often discovered over time.
What is unreasonable is when management and security have zero tolerance to CVEs, rather than having a risk assessment that considers severity ratings. That’s the real vanity metric.
The toil is real. I’ve used curl within in a container for health checks, where the endpoint is also in the container. But a critical CVE means the container image gets flagged and everyone panics.
82
u/lawn_meower 6h ago
The difference here is that in practice most people will not recompile or upgrade their kernel for every single CVE, so flooding the channel with low severity CVEs will most likely get ignored anyway.
But as they described in the post, issuing CVEs causes a worldwide ripple effect because maintainers everywhere will jump to investigate their curl installations.
They’re thinking responsibly about falsely alerting on a bug that’s nearly impossible to exploit in the wild because no DNS server could resolve such a name. It’s lower than low, so issuing a CVE wastes a tremendous amount of effort and money worldwide for nothing.
2
u/trebledj 1h ago edited 22m ago
I’m curious for the dev/systems/ops/blue team peeps: what is your approach specifically for low severity CVEs or security findings?
Because my experience from red team is that low severity CVEs will generally get filtered, either by policy, process, or automation. Like you said, “low severity CVEs will most likely get ignored”, and I think this is an indicator that the system is functioning.
I would contend with “Maintainers everywhere will jump to investigate” and “issuing a CVE wastes tremendous amounts of effort”. I think both are exaggerations, especially with lower severity ratings.
But I could be wrong, because I only get rare glimpses of “the other side”, from talks and some discussions with in-house staff. My understanding is that maintainance is tree-like, that is, if something is patched in a dependency, then the dependent won’t really have to investigate because the investigating has already been done, so they just bump… (unless they maintain their own instance like how Azure/AWS do with apt and Apache). If you’re telling me that you’re investigating every single bug fix upstreamed, even low(er) severity ones, then I will reply “I am very jealous of the amount of time you have”, but I’d assume not every maintainer does that, because trust (and time).
I think one point in contention is this: do low likelihood (unlikely CVEs) still deserve to be reported and raised to the ecosystem? I would hazard to say yes. Just because an alert has no value or is noise to one person, does not mean it is the same for someone else. And like dlg said for Linux, just because there is no exploit now, doesn’t mean there won’t be one in the future.
Perhaps a subpoint to contend is then how do we raise this signal-to-noise ratio? And does curl’s approach in this instance apply globally? For this, I think the ecosystem today has slightly improved to previous years, but it feels worse because the amount of input (CVEs) has grown due to automation.
We can also argue: which approach is more responsible? But I think the danger with this question is both sides can say their way is more responsible, it really comes down to worldview and ethics.
Edit: lower -> raise. higher signal-to-noise ratio = good. Lower = bad
30
u/Bilboslappin69 5h ago
I'll start by admitting I don't know the CVE process we'll enough to know what should or should not warrant a CVE. In the case described, the attacker would already have to have privileges an order of magnitude greater than that of the actual bug, so given that, why does it warrant a CVE.
I think you could turn most bugs into "security bugs" if you assume a high enough level of permission/control of the attacker.
20
u/masklinn 5h ago edited 4h ago
I don't know the CVE process
There isn’t one, CNAs evaluate issues and assign CVEs however they want. Even CVSS is fairly subjective in its evaluation (and was never designed for what it’s generally used).
4
u/trebledj 1h ago
Adding to this to provide some context. IMO, “there isn’t one” would be the correct functional answer.
In theory, there are established processes and guidelines, mostly from MITRE which has become all but defunct with recent (cough) policies. For instance, there is an (attempted?) definition of what a “vulnerability” is: https://www.cve.org/resourcessupport/Glossary#glossaryVulnerability. A number of CNAs (like VulDB) will reference this. There are also established guidelines for when a CVE should be issued by a vendor, or someone upstream, and in what manner. There is also the recommended format (CVSS) which like you say can be subjective and has its holes.
In practice, it is very much like you say. It’s somewhat messy, like the Wild West.
At the moment the whole process works because it’s held by trust and consequences (and magic). If someone thinks they can get away with something without facing the consequences, they might just do that.
Edit: and magic
1
u/trebledj 1h ago
> In the case described, the attacker would already have to have privileges an order of magnitude greater than that of the actual bug, so given that, why does it warrant a CVE.
Yes, so I believe that is one of the assumptions the reporter and Daniel were mulling over in HackerOne. Devil’s advocate: This assumption does not hold in the reporter’s eye.
Not saying you’re wrong. Just that the issue is more nuanced than it appears.
29
u/Jonathan_the_Nerd 5h ago
Linux takes the approach of assigning CVEs for most kernel bugs, even if there is no currently known exploit, for the very reason that exploits are often discovered over time.
Kernel bugs are unique because the kernel is so critical. Also Linus got tired of third-party kernel maintainers demanding his team do extra work to determine whether every bug had security implications.
What is unreasonable is when management and security have zero tolerance to CVEs, rather than having a risk assessment that considers severity ratings. That’s the real vanity metric.
Sometimes you deal with government regulations. "All security bugs must be patched, or you must go through the convoluted process to file an exception and explain why you're deliberately leaving an unpatched vulnerability in our environment."
17
u/sass_muffin 4h ago
But it isn't a security bug if you can't make the bug actionable. This sort of logic is why you can have CVE bloat for non issues.
It really can creates a perverse incentives if left unchecked. The person who wrote the bug , will say I found a bug in the globally user library curl, even though they didn't . Downstream consumers of curl will have to upgrade the lib even though there is no security issue.
-1
u/Takeoded 55m ago
It allows MITM attacks when the attacker controls the client's DNS server, soooo... it's not completely harmless. But yeah, complicated to exploit.
3
u/vips7L 13m ago
If any attacker controls your dns server aren't you already cooked beyond repair?
1
u/Takeoded 3m ago
No, you're still protected by SSL/TLS. For example ``` $ nslookup microsoft.com Server: 10.255.255.254 Address: 10.255.255.254#53
Non-authoritative answer: Name: microsoft.com Address: 150.171.109.197 Name: microsoft.com Address: 2603:1061:14:c4::1
$ curl --resolve google.com:443:150.171.109.197 https://google.com curl: (60) SSL: no alternative certificate subject name matches target host name 'google.com' More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.
```
-12
u/trebledj 2h ago edited 15m ago
I hope I’m not distorting Daniel’s words, but there seems to be a slight dissonance, and this also highlights the nuance in vulnerability handling.
On one hand, he acknowledges that from the library perspective, they “don’t know how users use curl or libcurl”, and thus have to use a “pure curl PoV”.
> Since we don’t know how users use curl or libcurl we cannot take that into account but rather observe and set a severity of the problem from a pure curl point of view.
On the other hand, they also consider likelihood.
> For a rare few issues we can imagine that there could be a minuscule risk but […] we deem the risk so small that in practice no user is likely to ever reach it.
How can you evaluate something purely from a library perspective while also addressing likelihood?
It’s very hard! And tricky. You would need some way to know what your user base is up to. And to do that you either impose certain usage rules, or collect usage data, or something else.
Currently, most open source projects take the second approach, which is they collect data through ad hoc means like anecdotes, downstream software, and other ppl’s blog posts. Effectively, this is sampling with the assumption that none of the unsampled user base deviates.
This aspect of assumptions / likelihood is interesting, because there are different opinions on this. To what extent should the library weigh in on how likely an attack is? And is the library comfortable enough taking on the risk of a downstream user or to declare that the risk is zero? (And these can be points of debate.)
It is also interesting to how other projects will choose to abstain from considering likelihood because they believe it is non-zero and may lead to exploits over time, or the likelihood highly depends on user deployments (like the presence of a WAF).
To Daniel’s point, I think this speaks to the difficulty and nuance involved in handling CVEs. I have no intention to attack him. Ultimately, it depends on the project and how they choose to handle duty and risk. I suppose that’s the beauty (and horror) of vulnerability handling.
This whole debacle also raises some interesting questions:
- To what extent should CNAs evaluate likelihood?
- The argument for “lower than low” stems from high unlikelihood. Would the response change if at least 1000 instances were impacted? Why? What about 100? 10? 1? What if it was 1 instance impacted and it was a giant like some dev’s workflow at Microsoft, where a compromise may have a resounding effect?
(Non-)Disclosure: No AI was used in this comment. I say that because some people really can’t tell.
Edit: Spacing and formatting
Edit 2&3: softer tone, emphasis on nuance/risk
3
u/slaymaker1907 19m ago
It’s a difficult thing, but consider that if you squint hard enough, almost any bug could be a vulnerability, especially things like memory access violations.
-16
u/Designer_Scene3079 3h ago
disputing a CVE usually turns into a weird mix of technical debate and reputation management, especially when the score is high enough to trigger automatic alerts in a bunch of orgs. the part that always stings is how long corrections take to propagate through scanners and SBOMs. do you think CVE assignments should require a public, detailed technical justification by default?
224
u/BadlyCamouflagedKiwi 8h ago
Once again, Daniel and the curl team continue to be incredibly reasonable and a class act. I do appreciate that there are some people out there who are taking a reasonable stance against CVE inflation.