The curl project will move low- and medium-severity vulnerability reports into its public GitHub issue tracker from October 26, reserving private handling for high- and critical-severity cases. Maintainer Daniel Stenberg said the change is a response to a sustained surge in submissions that has pushed the project’s small group of maintainers toward its limits. “Do minor curl vulnerabilities in the open” [3]
Under the new process, researchers who already know a report is low or medium severity should submit it as a public issue in the curl GitHub repository. Researchers who are unsure of a report’s severity can still use HackerOne; if curl classifies the submission below high severity, the project will ask the researcher to resubmit it publicly and close the private report as informational. Stenberg said more than 90 percent of submissions in recent years could quickly be assessed as below high severity. [3]
The policy applies to curl and libcurl, widely used for transferring data across network protocols, but it does not identify a new CVE, affected release, patch, proof of concept or exploitation campaign. Severity will be determined case by case rather than by a blanket version rule, so users should continue monitoring curl’s security documentation and release advisories for fixes tied to specific vulnerabilities.
Public disclosure could distribute triage, remediation and documentation work beyond the core team, allowing outside contributors to analyze reports and identify related defects before a release. It also removes the confidentiality buffer that normally gives maintainers time to prepare a fix, meaning defenders may see technical details before an update is available. The project is limiting the change to flaws it considers less serious because, as Stenberg argues, those issues are less likely to create immediate severe risk.
The move is the latest change to curl’s vulnerability-reporting process in 2026. The project ended monetary bug-bounty rewards in January after describing a flood of low-quality, often AI-assisted submissions, briefly shifted reporting to GitHub, and returned to HackerOne as its official reporting channel in March. Stenberg described the GitHub-only transition as a mistake [23], while later reporting said the volume of submissions nevertheless remained unusually high. [25]
For defenders, the practical response is to treat public curl issues as early-warning intelligence rather than proof that an exploitable vulnerability exists. Organizations should inventory curl and libcurl deployments, follow the project’s release and security notices, assess whether a disclosed issue affects their enabled protocols and configurations, and apply a vendor update when one becomes available. Researchers should avoid publishing sensitive details for reports they believe could be high or critical, and use the project’s private channel when severity is uncertain.
