Curl breaks up with HackerOne: end to the rewards and avalanche of reports generated by IA

The chief curl manager, the popular command line tool and its associated library, has decided to end the rewards program managed through HackerOne. According to the project documentation, the cessation will be effective at the end of January 2026 and the decision responds to a very low-quality avalanche of safety reports, many of them apparently generated by artificial intelligence tools.

Curl is a critical piece of the web ecosystem: is used to transfer data through a multitude of protocols and its libcurl library allows you to integrate that functionality into applications. If you want to consult the official documentation, the project keeps its site at curl.se and explains the integration with libcurl in its tutorial libcurl tutorial.

Since 2019, the curl team had used external channels - among them HackerOne and Internet Bug Bounty- to encourage responsible disclosure in exchange for economic compensation. However, in recent weeks the project has been documenting a sustained increase in reports that consume time from the maintainers without providing real findings: false positive, vague descriptions or reports that seem to "look good" at the drafting level but do not indicate reproducible vulnerabilities.

Daniel Stenberg, founder and chief curl developer, explained in his personal mailing list the reasons behind the change and detailed how such shipments are overloading the small team that maintains the project. You can read your message in the public list at This entry. In addition, Stenberg has shared examples illustrative enough to understand what kind of reports are motivating the decision; there is a public collection of these examples in Your Gist and their comments on social media are available at your publication in Mastodon.

The change is being formalized in the repository documentation: an pending update in the curl reward policy file ( Bug-BOUNTY.md) removes references to the HackerOne programme and clarifies that, from the date indicated, the project does not provide financial compensation for reported vulnerabilities or will not measure to obtain payments from third parties. The technical and process transition is described in the request to introduce these changes, available in GitHub.

What does this mean in practice? Until 31 January 2026 the project will continue to accept and process shipments made through HackerOne; the reports already initiated will continue to be processed. From 1 February, however, curl will ask that the findings be communicated directly by GitHub and will maintain an explicit position not to grant payments. The team has also updated its security files indicating that low-quality contributions will be sanctioned and that the aim is to reduce the noise that distracts the maintainers.

The official explanation highlights two closely related points: on the one hand, the shortage of active hands that support open source projects and, on the other, the massive arrival of automatic content that simulates valid reports. This phenomenon, sometimes described as the inundation of content generated by IA that brings little value, forces triage hours to classify and reject shipments rather than correct real failures. Stenberg has pointed out that the pressure on mental health and maintenance sustainability was decisive for making the decision.

This case raises broader questions about how to finance and secure free software projects in the automation age. Reward programmes provide clear incentives for those who find vulnerabilities, but they also introduce an economy that can attract volume of different quality shipments. If automation allows to generate requests and mass reproaches, the maintainers have to design filters and triage processes that, in turn, consume resources that many small repositories do not have.

It is possible that the withdrawal of curl from HackerOne does not completely stop the arrival of spurious reports, something that the team itself recognizes; the change aspires, that is, to cut off an economic incentive that was amplifying the problem. The security community and open source projects will have to continue to explore solutions: from improving the prioritization and automated filtering to looking for sustainable models of community or institutional funding for paid triage.

What can researchers and users do now? For those who find legitimate problems in curl or libcurl, the route indicated will be the direct presentation in the GitHub repository of the project, and it is appropriate to document clearly how to reproduce the failure and its impact. For the community at large, the episode serves as a reminder that the quality of technical communications is as important as vulnerability itself: a well-drafted and verifiable report remains the best way to collaborate.

Daniel Stenberg announced that he will publish a more detailed article about the change and the reasons behind it; until then, the primary sources of the movement are publicly available and are the most reliable reference to understand nuances. To check the current policy and project history, check the official repository in GitHub and the entries above.