What is changing
From October 26 2026, curl insists that vulnerability reports deemed LOW or MEDIUM severity be submitted as issues in its GitHub repository. Only vulnerabilities deemed HIGH or CRITICAL stay private in the HackerOne tracker.
The route depends on severity, not on a blanket rule. Researchers who are unsure can still use HackerOne. Maintainer Daniel Stenberg wrote that they can still submit there and curl will say what severity it deems the report. Reports curl judges LOW or MEDIUM will be asked to resubmit on GitHub. They will be closed as informative on HackerOne and publicly disclosed.
The mailing-list announcement matches this. It says that from Monday October 26, all vulnerabilities at severity LOW or MEDIUM are handled on GitHub, publicly and in the open.
Why curl says it has to do this
Stenberg frames the change as a survival measure. In his words, the policy is entirely triggered by the current avalanche of vulnerability reports. The project does not expect the flood to ease within the next several months. He says key maintainers feel strained and overloaded, and that this is a "next step" that "might not be our last."
He gives one figure: over the last few years, more than 90% of submissions could quickly be assessed as below HIGH. That is the maintainer's own account, not an independent audit. It also does not mean 90% of reports were invalid. It means they were not High or Critical.
The Register reports that Stenberg already shut down curl's bug bounty this year as AI-generated submissions piled work onto the security team. The current disclosure policy still states that there is no bug bounty and the project never offers rewards.
The AI "crazy combos" problem
Stenberg's post describes a trend he calls "crazy combos." Models generate odd sequences of libcurl options and protocol mixes that produce unexpected behavior. In his telling, these are sequences that real applications are unlikely to use. Or the unexpected result happens every time, so a developer would notice it at once. He argues that issuing CVEs for these issues saves no users and only creates work for the project and for everyone who has to react to the advisory.
He also says he aims to deny and decline more reports on the basis that they do not hurt users or existing applications. Dismissing every LOW report outright is not an option, though. The CVE program has an appeals process, and if curl does not issue a CVE for a real flaw, someone else will.
The trade-offs
Stenberg is open about the downsides.
- Workload per report does not shrink. The hope is that the burden can be shared among more people. Public discussion should also make lessons and documentation easier to find.
- Attackers get a head start. Stenberg says the policy gives bad actors a slightly longer window to exploit weaknesses. He calls this unfortunate but unavoidable, and limits the practice to below HIGH because those problems are "not terrible."
- Misclassification. Some people worry a researcher might file a High issue publicly, thinking it is Low or Medium. Stenberg calls understating a problem basically unheard of and notes that public filing was always possible.
- Downstream vulnerability management. The Mallory summary says community participants raised severity-misclassification and downstream concerns. It also says formal CVE records and security advisories will still accompany releases that contain fixes. I did not independently confirm that point from curl's own pages.
There is an upside for downstream users. Stenberg writes that the open process can let distros and other curl users keep up with security fixes earlier and better.
How this differs from the old process
The existing written policy says the opposite for security issues. It states that security vulnerabilities should not be entered in the project's public bug tracker and that no information should be public before the formal announcement. The same page already lets fixes for Low or Medium issues merge through a normal pull request without mentioning a security vulnerability. The new policy goes further. Now the report and discussion themselves go public. The policy page I reviewed still described the old workflow, so expect it to be revised.
curl uses four qualitative levels and does not support CVSS. Low means "truly hard or unlikely to exploit." High means a serious real-world problem that is not hard to trigger. Critical means a remote, unauthenticated, easy compromise in common configurations. Those are curl's definitions. Third parties may score curl bugs with CVSS and reach different conclusions.
Context: a busy month for curl
This follows a heavy release. Stenberg said curl 8.23.0 would ship on October 14 with fixes for 22 known vulnerabilities (Ubuntu's notice). Freenode's coverage counts 24, so the totals differ by source. One was assessed as high (CVE-2026-92392) and the rest as low or medium, according to Ubuntu. Freenode describes the high-severity bug as a use-after-free during HTTP/2 uploads.
The Hacker News reports that the HTTP/2 flaw was credited to Anthropic's OSS Scanner. Per that report, exploitation needs very specific conditions, so a crash is the most likely outcome. That helps explain why Stenberg says AI is both generating junk and finding real bugs. He has previously acknowledged that not all AI-assisted reports are bad.
He also notes that once a batch of CVEs ships, AI-using researchers feed the fixes to their models to look for similar mistakes or omissions. Public handling aims to get that scrutiny done before release.
What Windows admins and developers should do
From general industry knowledge, not the reporting above: curl.exe ships with current Windows versions, and libcurl is embedded in countless applications, installers and developer tools. A standalone curl update does not necessarily update every program that bundles its own libcurl.
- Watch the public tracker. Low and Medium issues may now appear on GitHub before a fixed release. Assign someone to watch it if curl is in your supply chain.
- Check exposure, not headlines. Compare affected versions, protocols and build options in a report against what you run. Low and Medium ratings are curl's judgment about general likelihood, not a verdict on your deployment.
- Inventory bundled copies. Find software that statically links or ships its own libcurl, since those copies need vendor updates.
- Rely on advisories for fixes. curl's vulnerability table lists affected releases per CVE and color-codes severity. Use it to scope remediation. The latest release shown there is 8.23.0.
- Researchers: submit via HackerOne if unsure of severity and let curl rate it. Don't email reports, because the project says it loses track of them.
Bottom line
curl is trading some secrecy for scale. The risk is bounded by the severity line and by Stenberg's argument that Low and Medium bugs are rarely dangerous. Whether public triage actually spreads the load is unproven. The project has reported no results yet, so claims of faster fixes or lower workload would be premature. It is also a notable signal that a project as widely deployed as curl says a flood of reports is threatening its ability to keep up. Other maintainers will likely be watching how it goes.