curl moves low and medium security reports into public view

Finding bugs got cheap. Judging them did not.

AI has made it easier to produce a security report. It has not made it easier to decide whether that report matters. That decision still takes a skilled human, and curl's maintainers say they are stretched to the limit.

Maintainer Daniel Stenberg set out a policy change on his blog on October 20. The project says it will no longer handle most security reports in private. Stenberg believes few software projects could withstand this volume for long, so curl may be an early example of a wider pattern.

What changes on October 26

From October 26, 2026, curl will insist that reports it judges LOW or MEDIUM severity be filed as public issues in its GitHub repository. Only HIGH or CRITICAL reports stay private in the HackerOne tracker. HackerOne is the platform where researchers have been sending reports confidentially.

Researchers who are unsure can still submit on HackerOne, and the team will tell them the severity. Reports judged LOW or MEDIUM will be closed there as informative and publicly disclosed. The submitter is asked to refile on GitHub.

Stenberg says over 90% of submissions in recent years could quickly be assessed as below HIGH. So most of the flow moves into the open.

Why the project says it has to act

Stenberg is blunt about the cause. He calls it an "avalanche" of reports and says the project sees no end to it. He writes that all key maintainers feel strained and overloaded, and that the project "must act to survive." He adds that this may not be the last step.

He also describes what many of the reports look like. Newly reported problems are often found by AI models that string together odd sequences of options. libcurl, curl's code library, has many options, protocol mixes and a flexible interface. Stenberg says the models try combinations nobody is likely to use in real software.

In other cases, the unexpected behaviour happens every time. An application doing that would show the problem at once. Stenberg says such reports carry almost no risk in the real world. They still cost the project time.

Why curl cannot simply ignore them

The project considered dismissing all LOW reports. It decided against that. Stenberg says the CVE program has an appeals process. If curl does not assign a CVE to a real vulnerability, someone else will. A CVE is the public ID given to a known security flaw.

So curl will keep handling true vulnerabilities. Stenberg says he will personally decline more of the reports he considers harmless to users and applications.

The trade-off, in the maintainer's words

Public handling has a cost. Stenberg acknowledges that open issues are visible to both good and bad actors. He concedes that attackers may get a little more time to act on a flaw, and that existing curl users carry that risk. He calls this unfortunate and sees no alternative. That is why the practice stops short of HIGH and CRITICAL.

He also addresses the risk that a researcher files a serious bug on GitHub by mistake. He calls it a low risk, since he says it is basically unheard of for researchers to understate a problem. He notes that accidental public reports were possible before.

On the other side, he expects benefits. More people can help assess a report, write the advisory and work out when the bug was introduced. He says a recurring pattern is that, once curl announces a batch of CVEs and fixes, many AI-using researchers feed them to their tools to look for similar mistakes. Opening the process could bring that scrutiny before a release ships. Distributions and other users could also see fixes earlier.

Stenberg is clear on the limit: the work per report does not shrink by doing it in public. The hope is to share it among more people.

What this means for your organisation

The lesson here is that AI-driven discovery shifts cost onto whoever must decide what is real. For curl, that is a small group of maintainers. For a company, it can be the security team or the vendors it relies on. Stenberg's report covers curl only. The pressure he describes may not be unique to it.

Leaders can put four questions to their teams:

First, do we know where curl and libcurl sit in our products and in our vendors' products? Second, does anyone watch curl's GitHub issues? Details of LOW and MEDIUM reports will now be public there. Depending on timing, that could happen before a fix is released. Third, does our patch policy treat MEDIUM as something that can wait, and is that still a safe assumption when details are public? Fourth, do we support, financially or otherwise, the open-source projects we depend on?

Cheap discovery has a price. Someone still has to pay it, and right now it is the maintainers.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: daniel.haxx.se.