The curl project will stop handling minor security bugs behind closed doors from 26 October, triaging low and medium severity reports in the open instead. Its lead developer says a relentless flood of submissions, many of them AI-assisted, has pushed the volunteer maintainers to breaking point.
What happened
On 20 October 2026 curl’s lead developer announced that the project is rewriting its vulnerability disclosure procedure. From Monday 26 October, any report the team rates as LOW or MEDIUM severity must be filed as an ordinary public issue in the project’s code repository rather than sent privately. Only flaws rated HIGH or CRITICAL will stay confidential on its bug reporting platform until a fix ships.
Researchers who are unsure how serious a finding is can still report it privately and ask for a rating. If the team decides it falls below HIGH, the reporter will be asked to refile it in public, and the private ticket will be closed as informative and disclosed.
The announcement, made by Daniel Stenberg in a post on his blog and reported by The Register, is blunt about the reason. He describes an “avalanche of vulnerability reports” with no sign of easing for months, and maintainers who feel stretched to the limit. He calls the move one step in a survival strategy and warns it may not be the last. In practice, low and medium reports will now go through GitHub issues, while HackerOne keeps the high and critical cases.
This comes after curl closed its paid bug bounty earlier in 2026, again citing the work created by AI-generated submissions.
How it works
curl uses four severity levels: LOW, MEDIUM, HIGH and CRITICAL. Until now, every claimed vulnerability was assessed privately. Fixes for minor issues could already land through normal public pull requests, but without being flagged as security fixes, and the assessment itself stayed hidden.
Under the new rules the whole lifecycle of a minor flaw becomes visible: the report, the debate over whether it is real, root cause analysis, working out which versions are affected, writing the advisory and checking the fix. The project’s argument is that more eyes will spread the load and catch incomplete fixes. Stenberg notes a pattern where, as soon as a batch of CVEs is published, researchers feed the patches into AI tooling to hunt for near-misses and related mistakes. Doing that scrutiny in public before release, the thinking goes, is better than receiving another wave of private reports afterwards.
The numbers explain the threshold. According to Stenberg, more than 90 per cent of submissions in recent years could be judged quickly as below HIGH. That is all submissions, not confirmed vulnerabilities, but it shows where the triage time goes.
He is also frank about the cost. Publishing minor bugs before a fix gives attackers a slightly longer window, which he calls unfortunate but unavoidable, and the reason the policy stops short of HIGH. The project considered ignoring LOW issues altogether but rejected that, because under the CVE system an unaddressed real flaw can simply be assigned an identifier by someone else. Instead, he intends to push back harder on reports describing odd option combinations that no real application would use.
Why it matters for UK organisations
curl and its library, libcurl, are among the most widely embedded pieces of software in existence. They ship inside operating systems, network appliances, cars, televisions, CI pipelines, container images and countless commercial applications used across UK businesses and the public sector. Very few organisations install curl deliberately; most inherit it several layers down in their supply chain.
That has two consequences. First, from next week details of minor curl weaknesses will be readable by anyone, including attackers, before patches are released and long before many vendors rebuild their products. Low and medium issues are rarely catastrophic, but in my experience they are exactly the kind of thing that gets chained with something else during a real attack. Second, it is a loud signal that the coordinated disclosure model many UK firms rely on is under strain. If one of the best-run open source security processes cannot cope with the volume, smaller projects your software depends on are unlikely to be faring better.
There is also a lesson for UK organisations running their own vulnerability disclosure policies or bounty programmes, including manufacturers that must publish a vulnerability disclosure policy for connectable consumer products under the UK’s Product Security and Telecommunications Infrastructure (PSTI) regime. The same flood of machine-generated reports that has overwhelmed curl will reach corporate inboxes too.
Expert view
I have a lot of sympathy for this decision. When we test, the noise in automated scanner output is one of the biggest time sinks, and the AI tooling now feeding bug bounty programmes is that problem at industrial scale. Every report, however implausible, demands a human to read it, reproduce it and argue about it. For a project run by a small core team, that cost is not abstract.
Calling this full disclosure would be unfair. HIGH and CRITICAL flaws remain under embargo, and the team keeps control of severity ratings. What changes is that the middle of the risk curve becomes visible earlier. For defenders that is a mixed blessing: attackers get a head start, but so do distribution maintainers and security teams who want to track fixes as they are written rather than when an advisory appears.
The bigger concern is what follows. curl’s own paid bounty has already gone, largely because of AI slop, and now its disclosure process is being reshaped by the same pressure. Unless the organisations profiting from open source fund triage capacity, I expect more maintainers to make similar trade-offs, and those trade-offs will shift risk onto users.
What to do now
- Know where curl lives. Use software bills of materials or software composition analysis to find libcurl in your applications, containers and appliances. This supports the Cyber Essentials requirements that in-scope software is supported and kept updated.
- Watch the public tracker. Have someone, or an automated feed, monitor curl’s public GitHub issues for security reports from 26 October so minor flaws affecting your use cases are spotted before an advisory lands.
- Keep patch timelines tight. Cyber Essentials requires high and critical security updates to be installed within 14 days of release; apply the same discipline to curl releases, and ask suppliers how quickly they rebuild with new libcurl versions.
- Harden how you call curl. Many reported issues depend on unusual option combinations. Review scripts and code for permissive settings, such as disabled certificate checks or unrestricted protocols and redirects.
- Prepare your own disclosure process. If you run a VDP or bounty, decide now how you will triage high volumes of AI-assisted reports, including severity thresholds and quality requirements for submissions.
Bottom line
curl is not abandoning coordinated disclosure, but it is admitting that the current model does not scale when machines generate reports faster than humans can read them. From 26 October minor curl flaws will be public before they are fixed. UK organisations should treat that as an early warning feed rather than a threat, and as a prompt to check whether their own disclosure arrangements could survive the same deluge.
