Recently, after I pointed out that Mythos only found a single low severity problem in curl in its first scan, countless people have repeated the claim that curl is one of the most scrutinized, most reviewed, most fuzzed and most verified source codes you can imagine. Perhaps that’s true, but I just want to mention this: that’s not by mistake. That’s not an accident or a happy circumstance. That’s the result of relentless work and attention to details through decades. Software engineering done right. Iterative improvements over time that simply never ends is an effective method.
This does not however mean that we don’t have bugs or that we don’t have security problems left, because we do. We have hundreds of thousands of lines of source code that is doing highly parallel networking for many protocols on all imaginable operating systems and CPU architectures – in C. So we fix the problems, patch them up and ship new releases. Over and over.
[...]
The rate of incoming security reports is 4-5 times higher than it was in 2024 and double the speed of 2025 – meaning that on average we now get more than one report per day. The quality is way higher than ever before. The reports are typically very detailed and long.
In order to manage this incoming flood of submissions, we need to make sure to handle them as soon as possible as we know there are more coming. If we don’t take care of them roughly at the same speed they arrive, the backlog just grows and having that list of potential security problems in a list that you don’t have control over takes a mental toll.
[...]
For the first time in my life, my wife voiced concerns about my work hours and my imbalanced work/life situation. I work more than I’ve done before, but the flood keeps coming. People in my surrounding, I guess reading between the lines, have asked me how I and we cope with this deluge and want to make sure we don’t burn in the process. I am concerned for my team mates.
I might soon have to reduce my work hours to allow myself more breathing time.
[...]
With about half the release cycle left until the pending release ships, we already have twelve confirmed vulnerabilities meaning twelve pending CVE announcements. That’s a new project record and it also means we will reach thirty published CVEs in 2026 even before half the calendar year has passed. The projected total amount of curl CVEs published through the whole year is therefore at least double this number!
[...]
Fixing bugs and problems is good. Every reported problem implies a fixed issue. curl becomes a better product.
What is also a good trend: almost no one finds terrible vulnerabilities. All vulnerabilities found the last few years in curl have all been deemed severity LOW or MEDIUM. I’m not saying there won’t be any more HIGH ever, but at least they are rare. The most recent severity high curl CVE was published in October 2023.
I think it is clear that we have overcame the slop era, for vulnerabilities and these things are delivering clear value. Of course, in the hands of amateurs like it was before, it is useless. Of...
I think it is clear that we have overcame the slop era, for vulnerabilities and these things are delivering clear value. Of course, in the hands of amateurs like it was before, it is useless. Of course, LLMs do not have a 100% (or even a 80%) hit rate. But in the hands of people that know that they are doing, we are seeing more vulnerabilities than ever before.
And yes... that's awful for the poor people that need to fix them. God knows how we deal with this mess.
From the article:
[...]
[...]
[...]
[...]
I think it is clear that we have overcame the slop era, for vulnerabilities and these things are delivering clear value. Of course, in the hands of amateurs like it was before, it is useless. Of course, LLMs do not have a 100% (or even a 80%) hit rate. But in the hands of people that know that they are doing, we are seeing more vulnerabilities than ever before.
And yes... that's awful for the poor people that need to fix them. God knows how we deal with this mess.