TL;DR
- curl is an open-source data transfer tool, and libcurl is the library inside it that applications call to fetch and send data over network protocols.
- From 26 October 2026, every vulnerability report the project rates LOW or MEDIUM goes into curl's public GitHub issue tracker, and only HIGH and CRITICAL reports stay private in the HackerOne queue.
- The maintainer's own count puts over 90 percent of submissions below HIGH, which makes the public tracker the main path for most of the reporting work.
- Public handling gives the project more people to assess a report, write the advisory and check for related problems before a release ships, and it hands attackers a longer window on flaws that stay unfixed.
- The trigger is volume: Daniel Stenberg describes maintainers brought to the brink of what they can muster and a survival strategy that may take further steps.
- From 26 October onward, a team following curl will see most of the project's vulnerability reports handled in public GitHub issues, and a stack that takes libcurl from a distribution still gets the fix as a package update.
The curl project's own Vulnerability Disclosure Policy page (curl.se/dev/vuln-disclosure.html, captured 2026-10-20), which states the private reporting process that the 26 October change narrows to HIGH and CRITICAL reports.
What changes on 26 October
The new routing is short. Reports rated LOW or MEDIUM go to the project's GitHub repository as issues, and HIGH or CRITICAL reports stay in the HackerOne tracker. A researcher unsure of the severity can still file on HackerOne, where the project will tell them how it reads the report, and anything it judges LOW or MEDIUM gets asked back to GitHub and closed as informative on HackerOne.
As read on 2026-10-20, the project's published policy page still describes the older shape of the process: report privately, keep the information out of public view until the vulnerability is formally announced at the end of the process, and expect a member of the security team to acknowledge that a human has seen the report. That page and the new routing now describe two different intake paths for the same project, and the split line is the severity rating.
Ninety percent of reports arrive below HIGH
The number that explains the decision is in the announcement. Over the last few years, over 90% of all submissions could quickly be assessed to be less than HIGH, Stenberg writes, which means the private queue has been carrying a volume of low-grade reports that the project rates as minor. Part of the reason is method: many newly reported vulnerabilities are figured out by AI models that create unusual sequences or option combinations that do something unexpected, and Stenberg told The Register those combinations are unlikely to occur in real applications.
Netics editorial diagram built from the 2026-10-20 announcement: a rising report count is often read as harder scrutiny, while curl's own assessment places over 90 percent of submissions below HIGH severity.
The workload shows in the language he uses. All key maintainers feel strained, overloaded and brought to the brink of what they can muster, and the project states plainly that it must act to survive. The project does not anticipate the flood to decrease within the next several months. It had already shut down its bug bounty scheme earlier this year, after AI-generated submissions piled work onto its security team.
What public handling gives the project
An open tracker puts more eyes on the same report. Someone else can reproduce the crash, argue about the severity, draft the advisory text, or notice that the fix misses a neighbouring case, and the project gets that work before a release ships. Stenberg adds that the open process can also allow distros and other users of curl to keep up with security fixes earlier and better.
Stenberg names a pattern that makes the sharing useful. The moment a new set of CVEs and fixes is announced, an army of AI-using researchers throws those at their models to find similar mistakes or omissions in the fixes, and moving the process into public gives the project more help with that scrutiny.
He is precise about the limits of the change. The amount of work per report stays the same, and the four severity levels the project uses stay LOW, MEDIUM, HIGH and CRITICAL. Public handling opens the queue to more people who can see it and help drain it. The project cannot ignore true LOW issues, because the CVE program has an appeals process and, if curl does not hand out a CVE for an actual vulnerability, someone else will.
Netics editorial statistic card from the 2026-10-20 announcement: over 90 percent of submissions over the last few years were assessed below HIGH severity by the curl project.
The window this opens for attackers
Public handling makes a flaw visible to everyone reading GitHub, which includes people who will try to exploit it before a fix exists. Stenberg says so directly: this policy gives bad people a slightly longer window of opportunity at the expense of existing curl users, and the project limits the practice to less than HIGH for that reason.
The judgement behind that trade is worth stating. A LOW or MEDIUM flaw in libcurl can still matter to a specific application, and a public issue shows it to anyone watching before the fix ships. The pattern is that AI tooling has made vulnerability reports cheap to produce, and judging each one still takes as much maintainer work as ever; Stenberg concedes that public handling leaves that work as heavy as before. Opening the queue spreads the judging across more people. curl's answer is a severity split of one intake: public GitHub issues below HIGH and a private tracker for HIGH and CRITICAL, with the CVE appeals process forcing the project to keep handling true LOW issues and the attacker window setting where the line falls.
How a team should read a curl advisory after the change
Start with where curl comes from. A stack can receive libcurl through a distribution package, a base image or a language runtime, and in that case the fix that matters arrives as a package update.
Daniel Stenberg's announcement of 20 October 2026 on daniel.haxx.se (captured the same day), which sets out the 26 October change, the HackerOne path for HIGH and CRITICAL reports, and the reasoning behind both.
Take a concrete case. Imagine a hypothetical SaaS team, an illustration of Stenberg's point that the open process lets distros and other users of curl keep up with security fixes earlier and better. It pins libcurl through its distribution and pulls container base images monthly; from 26 October, the LOW and MEDIUM reports that could touch its stack are visible in curl's GitHub issues while the project assesses them. Watching the project's repository gives that team early warning about which functions and option combinations are drawing attention, which is the earlier and better tracking of fixes that Stenberg expects for distros and other users of curl.
The practical task is to map each public curl issue to the package or image that carries libcurl; that dependency map also supports a security audit and hardening of the stack itself. Read the public issues for signal about exposure, then act on the packaged fix, and treat the private advisory as the case that still deserves a fast, quiet response.
Originally published on the Netics blog.
Top comments (0)