curl takes low and medium vulnerability reports public to cope with an AI-driven flood

What curl is changing

The curl project is changing how it handles security reports. In a post on 20 October 2026, lead developer Daniel Stenberg wrote that from 26 October, any vulnerability report the project judges to be of LOW or MEDIUM severity should be filed as a public issue in curl's GitHub repository instead of being handled privately. Only HIGH and CRITICAL problems will stay confidential on HackerOne, the platform curl uses for private reports.

Researchers who are unsure how serious their finding is can still send it to HackerOne first, and the curl security team will tell them which severity it assigns. If the team rates a HackerOne report LOW or MEDIUM, the reporter will be asked to resubmit it on GitHub, and the HackerOne report will be closed as informative and publicly disclosed.

That is a big change for one of the most widely used pieces of software in the world. curl and its library, libcurl, transfer data in countless operating systems, devices and applications, and until now every suspected vulnerability went through a private embargo process before being announced with a release.

Why: an avalanche of reports

Stenberg is blunt about the reason. The policy change, he writes, is entirely triggered by the current avalanche of vulnerability reports, and the project sees no end to it and does not expect the flood to decrease within the next several months. All key maintainers feel strained and overloaded, and he describes the move as the next step in a survival strategy that might not be the last.

He also gives a number that explains why the line is drawn where it is. Over the last few years, more than 90% of all submissions could quickly be assessed as less than HIGH severity. In other words, the vast majority of the private, embargoed work the team was doing concerned problems it does not consider serious.

AI is at the centre of his explanation. Many newly reported vulnerabilities, he writes, are found by AI models that try odd sequences or combinations of options that do something unexpected, but in ways nobody is likely to use in the real world, or that would fail so visibly every time that an application would notice at once. libcurl has an almost endless number of option and protocol combinations, and he expects AI tools, and the people driving them, to keep trying them all and treating every minor discrepancy as a vulnerability.

There is a second AI effect. Whenever curl publishes a set of CVEs and fixes, Stenberg writes, an army of AI-using researchers throws them at their models and harnesses to look for similar mistakes or gaps in the fixes. Doing the work in public is partly a way to have that scrutiny happen before a release rather than after.

How the new process will work

curl's vulnerability disclosure policy currently says security problems should not be entered in the public bug tracker, and describes a private process: the security team assesses a report, works out a fix in a private branch, warns Linux distributions shortly before release and announces the issue with the release. The policy also states that there is no bug bounty and curl never pays rewards for reported vulnerabilities.

Under the new approach, LOW and MEDIUM issues skip the embargo. Stenberg argues that opening the process lets anyone help assess a report, check whether the fix is correct and complete, spot related problems nearby and write the advisory, and that Linux distributions and other users can follow security fixes earlier. He concedes that the work per report does not shrink, but hopes it can be shared among more people.

The project uses four severity levels and deliberately avoids numerical CVSS scores, which its policy calls a broken system. LOW covers problems that are truly hard or unlikely to exploit or trigger, and MEDIUM covers ones that are less hard but usually need something else to happen to become serious. The policy already says that low and medium reports limited to releases more than three years old are closed without action.

Stenberg also says he personally aims to push back harder on reports that do not hurt any real users. The team considered simply dismissing all LOW issues, he writes, but within the CVE system an actual vulnerability that curl refuses to register can still get a CVE through an appeal or from someone else, so real issues cannot simply be ignored.

AI finds real bugs too

The change is not a rejection of AI-assisted security research as such. Days earlier, Stenberg published an audit of curl by AISLE, whose engineers had pointed AI-powered tools at curl's source for about a year. That work produced 35 published curl vulnerabilities, more than any other group or individual has found, and he describes the cooperation as entirely positive, backed by skilled humans who also wrote fixes. AI Lookout covered AISLE when Cohere agreed to buy it.

curl 8.23.0, released on 14 October, also fixed one of the worst curl bugs in a long time: an HTTP/2 upload use-after-free rated HIGH that could, under a narrow set of conditions, let a malicious server run code on the client. Stenberg's write-up of that bug lists the conditions that made it hard to exploit in practice. Bugs of that class would still be handled privately under the new rules.

The tension is between quality and volume. Automated tools are getting better at finding real flaws, as shown by results such as Anthropic's automated red-teamer beating human bug bounty hunters, but the same tools make it cheap to produce large numbers of low-impact or unverified reports, and the cost of triaging them falls on small volunteer teams.

The risks curl accepts

Stenberg lists the downsides himself. Handling some vulnerabilities in public makes them immediately visible to attackers as well as defenders, giving bad actors a slightly longer window to exploit weaknesses before a fixed release ships. He calls that unfortunate but unavoidable, and says limiting the practice to less than HIGH severity keeps the exposure to problems that are not terrible.

Others have raised the risk that a researcher underestimates a serious bug and posts it publicly as LOW or MEDIUM. Stenberg considers that unlikely, saying it is basically unheard of for a researcher to understate a problem, and points out that someone could always have filed a vulnerability publicly before. The safety valve is that anyone unsure can still go to HackerOne first.

What it means for other projects

curl is a bellwether for open source security practice, and other maintainers facing the same flood of AI-assisted reports will be watching how this works. Stenberg writes that he believes few software projects can withstand this kind of prolonged, high-volume deluge, and that something has to give.

For users and vendors that ship libcurl, the practical change is that some security fixes will be discussed and visible on GitHub before a release, rather than appearing only in advisories on release day. Security teams that track curl may want to watch its issue tracker as well as its announcements. As AI agents themselves become software that needs securing, as in the Archon coding-agent flaw, the pressure on maintainers to triage more reports is unlikely to ease soon.