curl Moves Minor Vulnerability Reports Into the Open

The curl project will start handling most of its security bug reports in public, its lead maintainer Daniel Stenberg said in a blog post on 20 October 2026. From 26 October, reports rated LOW or MEDIUM severity should be filed as open issues on GitHub, rather than privately.

Stenberg said the change is “entirely triggered by the current avalanche of vulnerability reports that keep pouring in”. He linked much of that flood to researchers using AI tools.

curl is a free, open-source tool and code library for moving data over the internet. It is built into a huge range of software and devices, so changes to how it handles security bugs matter well beyond its own small team.

In brief

From 26 October, curl wants LOW and MEDIUM vulnerability reports filed publicly on GitHub. Only HIGH and CRITICAL reports stay private on HackerOne.
Stenberg says over 90% of submissions in recent years could quickly be judged less than HIGH.
He accepts the change gives attackers “a slightly longer window of opportunity”, but says the team must act “to survive”.

What is changing?

Until now, security reports to curl went through HackerOne, a platform that lets researchers report bugs privately. Under the new rule, “all vulnerability reports submitted to us that are deemed to be severity LOW or MEDIUM should instead be submitted as issues in our GitHub repository,” Stenberg wrote.

“Only vulnerabilities deemed to be HIGH or CRITICAL will be kept private in the HackerOne tracker,” he added.

Researchers who are unsure can still use HackerOne, and the curl team will tell them how severe it thinks the issue is. Reports rated LOW or MEDIUM there will be closed as “informative” and the reporter asked to resubmit on GitHub, Stenberg said.

Severity	Where to report from 26 October
LOW	Public GitHub issue
MEDIUM	Public GitHub issue
HIGH	Private, on HackerOne
CRITICAL	Private, on HackerOne

Source: Daniel Stenberg’s blog, 20 October 2026.

Why is curl doing this?

Stenberg was blunt about the reason. “We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster,” he wrote. “We must act to survive. This is our next step in a survival strategy. It might not be our last. We aim to not drown.”

When he first proposed the change in a GitHub discussion on 17 October, he wrote: “Today (a Saturday) we received 13 vulnerability reports. We cannot handle managing them in secret within our tiny team.”

He also said most reports are not serious. “Over the last few years, over 90% of all submissions could quickly be assessed to be less than HIGH,” he wrote on his blog. In the GitHub discussion, he said that over the last five years curl has had three HIGH issues “and maybe a hundred LOW / MEDIUM vulnerabilities”.

Stenberg had already closed curl’s bug bounty programme this year as AI-generated reports piled up, according to The Register.

What role does AI play?

Stenberg said that “many newly reported vulnerabilities are figured out by AI models that create crazy sequences or option combinations that do something unexpected”. He said these combinations are rarely, if ever, used in real software.

He also described a pattern after each security release. “An obvious recent trend is that the moment we announce a new set of CVEs and their associated fixes, there is an army of AI-using researchers who throw all those at their models and harnesses to find similar mistakes or omissions in the fixes,” he wrote.

A CVE is a public identifier for a known security flaw. Stenberg said curl cannot simply ignore low-severity issues. Under the CVE programme, if curl declines to assign a CVE to a real vulnerability, “then someone else will do it”, he wrote.

What are the risks?

Stenberg accepted that public reports carry a cost. “This policy will give bad people a slightly longer window of opportunity to exploit weaknesses at the expense of existing curl users,” he wrote. “That is unfortunate but we see no way of avoiding this.”

He said that is why the change stops at MEDIUM: “at least these problems are not terrible”.

Some people worried that researchers might file a serious bug publicly by mistake, thinking it was minor. Stenberg called that “a low risk scenario”, saying it is “basically unheard of that a researcher would have understated a reported problem”.

What could the project gain?

Stenberg said open handling lets “the whole world” help assess reports, check fixes and write advisories. He hopes more eyes will catch related mistakes “before we ship releases”, and said it could help Linux distributions and other users of curl keep up with fixes earlier.

He was clear that the work per report will not shrink, but wrote that “we think that we might share the burden among more people easier”.

Our read

This is TSN’s analysis. curl is one of the most widely used pieces of open-source code, and its maintainers are saying out loud what many small projects are feeling: AI has made finding minor bugs cheap, but fixing and triaging them is still slow, human work. Moving LOW and MEDIUM reports into the open trades a little secrecy for help and transparency. For curl users, the practical step is unchanged: keep curl and the software that bundles it up to date.