There's something unnerving about this blog post.

Paraphrasing: "The world's top security researches and AI labs are pouring all their VC money into finding as many security issues in curl as possible". At the same time, we know that curl is run by volunteers that needs to handle all of this. I'm not saying that we shouldn't do security review of open source libraries, just saying that this situation puts a lot of pressure on the maintainers.

The second unnerving thing is that many of the listed vulnerabilites target embedded libcurl; a library with a much slower update cycle. I'm guessing that many of the listed bugs are still in active use, inside the thousands of applications that use curl internally. Another tricky situation.

Both of these stand in contrast to the posts "braggy" style of "we found the most vulnerabilities of all!!!".

Would be great if people would brag with quotes and feedback from the maintainers. I'd be more interested to see that. Instead our model found x, I want something that really helps the maintainers.

Another way to read it is that the public now have access to resources on a scale that was formerly the domain of three letter government agencies throwing millions of dollars to hire humans to do this work. While in the short-term it's painful for maintainers, in the long-term we all end up safer.

If they don't do it, somebody else will. It's better white hats get there first.

> The second unnerving thing is that many of the listed vulnerabilites target embedded libcurl; a library with a much slower update cycle.

I am guessing the slower update cycle is an issue where it is statically linked?

> I'm not saying that we shouldn't do security review of open source libraries, just saying that this situation puts a lot of pressure on the maintainers.

This is true, and worth saying, but it is also a problem of the OSS philosophy. All software is used at your own risk, so if maintainers want their software used they need to keep up, and the (true) promise of "more eyeballs means more secure software" has this downside built in.

It's all things at once.

It's good that the world has thrown enormous resources into finding curl bugs, and found not very much. Most of the CVEs are low priority and in the more esoteric parts of curl. Some (like CVE-2026-9080) seem so obscure, I'm doubtful anyone other than the reporters have ever experienced it. That shows that curl was already pretty good to begin with.

This is ultimately a marketing piece for Aisle, but at least they did some public good to get their marketing.

The most important part is that these researchers were respectful of the maintainers, and spent their own time and money fully verifying their findings before raising them with the project. They have taken on board the message that the curl project won't even talk to slop flingers. The less diligent researchers, the Dunning-Krugerands who feel enabled by AI but actually just waste the maintainers time, are the real problem.