Do minor curl vulnerabilities in the open
B · Useful, limited curl's lead maintainer announces a primary policy change driven by AI-assisted report volume; useful first-hand signal, but the evidence is one rough share and the maintainers' own account of strain.
Summary based on the full text·Original: about 4 minutes to read
In short
Daniel Stenberg, lead maintainer of curl, announced on 20 October 2026 that from 26 October the project will handle LOW and MEDIUM severity vulnerability reports as public GitHub issues. Only HIGH and CRITICAL reports stay private on HackerOne. The stated cause is an ongoing flood of reports, many generated with AI models, that has left key maintainers "strained, overloaded".
Key numbers
- October 26 2026date from which LOW and MEDIUM curl vulnerability reports must go to public GitHub issues
- over 90%share of submissions in recent years quickly assessed as below HIGH severity
As reported by the source.
English·Web page·opens daniel.haxx.se
What it reports
- Reports deemed LOW or MEDIUM that arrive on HackerOne will be closed as informative, publicly disclosed, and the reporter asked to resubmit on GitHub. Researchers unsure of severity can still use HackerOne for a ruling.
- Over 90% of submissions in recent years could quickly be assessed as less than HIGH.
- Stenberg expects the flood not to decrease "within the next several months".
- After each CVE announcement, AI-using researchers run the fixes through models to find similar mistakes; opening the process aims to get that scrutiny before release.
- Many new reports come from models producing unusual option combinations unlikely to occur in real use, or behaviour that would be obvious to any application on first run.
- Dropping LOW issues entirely was considered and rejected: under the CVE appeals process, someone else would assign the CVE.
- Accepted cost: public handling gives attackers a slightly longer window on minor issues, which is why HIGH and above stay private.
How they got it
A maintainer's policy post based on the project's own report handling. The 90% figure is an approximate share from curl's experience, with no count or time series given.
Limits
- One approximate number; no report volumes, trend data or share attributable to AI tools.
- The post states intent; the effect of the change on maintainer load is not yet known.
- Single project, though widely used.
Why it matters for companies
Companies that depend on open source should expect maintainers to change disclosure rules under AI-driven report volume, and more minor issues to be public before a fix ships. Security teams need to watch project issue trackers, not just CVE feeds. Organisations running AI-assisted scanning against third-party code should triage before submitting: low-value reports now have a visible cost to the projects everyone relies on.
Summary based on the full text. Read the original for the full argument and data.Read the original on daniel.haxx.se