The curl vulnerability policy changed today. From 26 October 2026, reports the project grades LOW or MEDIUM must be filed as public GitHub issues, and only HIGH and CRITICAL stay private on HackerOne. Maintainer Daniel Stenberg said the change was triggered entirely by an avalanche of incoming reports.
What Changes for Vulnerability Reporters
The severity of a flaw now decides whether it is discussed in public from the moment it is reported. curl is the command-line tool and library for transferring data over the internet, maintained as an open-source project and bundled into operating systems, phones, cars and appliances.
| Severity curl assigns | Where it is handled | Public from the start? |
|---|---|---|
| LOW | GitHub issue in the curl repository | Yes |
| MEDIUM | GitHub issue in the curl repository | Yes |
| HIGH | HackerOne, privately | No, until a fix ships |
| CRITICAL | HackerOne, privately | No, until a fix ships |
| Unsure | HackerOne; the project states the severity it assigns | Depends on the grade given |
Email is not an option at any severity. The project’s documentation states that it “cannot handle vulnerability reports sent to us over email”. As of 26 October 2026 the policy is in force and curl’s own bug bounty documentation has been rewritten to match it.
What Happens if You Grade a Report Wrong
A private report that curl downgrades does not stay private. If a submission filed on HackerOne is assessed as LOW or MEDIUM, the reporter is asked to resubmit it as a GitHub issue, and the HackerOne report is closed as informative and publicly disclosed.
Stenberg judged the opposite error to be unlikely. Writing that “It is basically unheard of that a researcher would have understated a reported problem”, he treated the risk of a genuine HIGH flaw being filed in the open as small enough to accept.
Reporters who genuinely cannot tell are told to use HackerOne, where the project will assign and communicate a severity rather than leaving them to guess.
curl Grades Without CVSS, and Pays Nothing
Two features of curl’s process change what this policy means in practice, and neither is a new decision taken this week.
The first is that curl does not score vulnerabilities numerically. It uses four named levels — Low, Medium, High and Critical — and its documentation says plainly: “We do not support CVSS as a method to grade security vulnerabilities.” A reporter cannot therefore calculate in advance which side of the public-private line a finding falls on, as they could with a numerically scored flaw of the kind that produces a CVSS 10.0 rating. The grade is curl’s judgement, communicated after the fact.
The second is money, and it is the part of this story that has gone largely unmentioned. curl has no bug bounty to lose. The project’s documentation states that “There is no bug bounty and the curl project never offers rewards for reported vulnerabilities”. That has been true since the end of January 2026, when curl closed the bounty it had run on HackerOne, recording the change in its own repository with the line: “Up until the end of January 2026 there was a curl bug bounty. It is no more.”
Today’s change is therefore the second structural move the project has made against the same problem in nine months. The first removed the payment incentive to submit. The second removes the privacy.
Why curl Changed the Policy
Stenberg set out the reasoning in a post on 20 October 2026. He wrote that “This policy change is entirely triggered by the current avalanche of vulnerability reports”, said that “all key maintainers feel strained, overloaded”, and expected the volume to persist for several months.
The figure that makes the split workable is his own assessment that, over the last few years, more than 90 percent of submissions could quickly be judged as less than HIGH. Moving that majority into the open leaves the small remainder to be handled privately.
He named three benefits he expects, all of them about distributing labour rather than reducing it:
- More hands on assessment: anyone can help judge whether a reported issue is real, instead of the security team alone.
- Public review of fixes: Stenberg noted that AI-assisted researchers scrutinise new fixes as soon as a CVE is announced, and hoped public handling would surface incomplete fixes before a release ships rather than after.
- Earlier fixes downstream: Linux distributions and other large users can see and take fixes sooner than they would under embargo.
He was explicit that the change does not cut the work each report costs. It spreads that work across more people.
The Risk curl Accepted
Handling a flaw in public gives an attacker a window between disclosure and a shipped fix. Stenberg acknowledged this directly and said it is the reason the change stops below HIGH: the issues now discussed openly are, by the project’s own grading, the ones least worth exploiting.
He also said curl will not simply dismiss every LOW report to clear the queue, because the CVE appeals process means someone else could assign a CVE to a problem the project waved away. What he did signal is more rejections of reports that do not affect real users or applications, including AI-discovered edge cases with triggers he describes as unlikely or self-evident.
For anyone reading curl’s GitHub issues from now on, the practical caution is that a public security issue is not evidence of a serious flaw. It is closer to the opposite: under this policy, the open ones are the minor ones. Serious flaws in widely used components still move privately until a patch exists, as the handling of the recent PHP2Shell vulnerability and its fixed versions showed.
Frequently Asked Questions
What Is the New curl Vulnerability Policy?
From 26 October 2026, vulnerability reports curl grades LOW or MEDIUM are handled as public GitHub issues. Only reports graded HIGH or CRITICAL remain private on HackerOne until a fix is released.
Where Do I Report a curl Vulnerability Now?
File a GitHub issue in the curl repository if you judge the severity below HIGH, and use HackerOne for HIGH or CRITICAL. If you cannot judge it, use HackerOne and the project will tell you the severity it assigns. Email reports are not accepted.
Does curl Pay for Vulnerability Reports?
No. curl’s documentation states there is no bug bounty and that the project never offers rewards at any severity. The bounty it previously ran ended at the end of January 2026.
Why Did curl Make Low-Severity Reports Public?
Stenberg cited an avalanche of incoming reports and said all key maintainers feel overloaded. He expects public handling to let more people share the assessment work and to get fixes to Linux distributions sooner.
Does a Public curl Security Issue Mean My System Is at Risk?
Not on its own. Under this policy a publicly handled issue has been graded below HIGH, so an open GitHub issue signals a minor problem rather than an urgent one.
