Curl rompe com HackerOne: fim às recompensas e a avalanche de relatórios gerados por IA

O principal responsável pelo curl, a popular ferramenta de linha de comandos e sua biblioteca associada, decidiu terminar com o programa de recompensas gerenciado por HackerOne. Segundo a documentação do projeto, a cessação será efetiva no final de janeiro de 2026 e a decisão responde a uma avalanche de relatórios de segurança de muito baixa qualidade, muitos deles aparentemente gerados por ferramentas de inteligência artificial.

Curl é uma peça crítica do ecossistema web: é usado para transferir dados através de múltiplos protocolos e sua biblioteca libcurl permite integrar essa funcionalidade em aplicações. Se você quiser consultar a documentação oficial, o projeto mantém seu site em curl.se e explica a integração com a libcurl em seu tutorial libcurl tutorial.

Desde 2019, a equipe de curl havia recorrido a canais externos — entre eles HackerOne e o Internet Bug Bounty — para incentivar a divulgação responsável em troca de uma compensação económica. No entanto, nas últimas semanas, o projeto tem sido documentando um aumento sustentado de relatórios que consomem tempo dos mantenedores sem fornecer achados reais: falsos positivos, descrições vagas ou relatórios que parecem “lucir bem” a nível de redação, mas não sinalizam vulnerabilidades reprodutíveis.

Daniel Stenberg, fundador e desenvolvedor principal de curl, explicou em sua lista de e-mails pessoais os motivos por trás da mudança e detalha como esse tipo de envio está sobrecarregando a pequena equipe que mantém o projeto. Você pode ler sua mensagem na lista pública esta entrada. Além disso, Stenberg compartilhou exemplos bastante ilustrativos para entender quais tipos de relatórios estão motivando a decisão; há uma coleta pública desses exemplos em seu Gist, e seus comentários em redes sociais podem ser consultados em sua publicação em Mastodon.

A mudança é formalizada na documentação do repositório: uma actualização pendente no ficheiro de políticas de recompensas do curl ( BUG-BOUNTY.md) elimina as referências ao programa de HackerOne e esclarece que, a partir da data indicada, o projeto não oferece compensações econômicas por vulnerabilidades relatadas ou mediará para obter pagamentos de terceiros. A transição técnica e de processos está descrita no pull request que introduz essas mudanças, disponível em GitHub.

O que isso significa na prática? Até 31 de janeiro de 2026 o projeto continuará aceitando e processando envios feitos através de HackerOne; os relatórios já iniciados continuarão seu processamento. A partir de 1 de fevereiro, porém, curl pedirá que os achados sejam comunicados diretamente pelo GitHub e manterá uma postura explícita de não conceder pagamentos. A equipe também atualizado seus arquivos de segurança indicando que as contribuições de baixa qualidade serão sancionadas e que o objetivo é reduzir o ruído distraindo os mantenedores.

A explicação oficial destaca dois pontos intimamente relacionados: por um lado, a escassez de mãos ativas que sustentam projetos de código aberto e, por outro, a chegada massiva de conteúdo automático que simula relatos válidos. Esse fenômeno, às vezes descrito como a inundação de conteúdo gerado por IA que traz pouco valor, obriga a dedicar horas de triage a classificar e rejeitar remessas em vez de corrigir falhas reais. Stenberg afirmou que a pressão sobre a saúde mental e a sustentabilidade da manutenção foi determinante para tomar a decisão.

Este caso levanta questões mais amplas sobre como financiar e garantir projetos de software livre na era da automação. Os programas de recompensa oferecem incentivos claros para quem encontre vulnerabilidades, mas também introduz uma economia que pode atrair volume de remessas de qualidade diversa. Se a automação permite gerar pedidos e reproches em massa, os mantenedores têm que projetar filtros e processos de triage que, por sua vez, consomem recursos que muitos repositórios pequenos não têm.

É possível que a retirada de curl de HackerOne não pare completamente a chegada de relatórios espurios, algo que a própria equipe reconhece; a mudança aspira, isso sim, cortar um incentivo econômico que estava amplificando o problema. A comunidade de segurança e os projectos de código aberto terão de continuar a explorar soluções: desde melhorar a priorização e a filtragem automatizada até procurar modelos sustentáveis de financiamento comunitário ou institucional para a triage remunerada.

O que podem fazer pesquisadores e usuários agora? Para aqueles que encontrem problemas legítimos em curl ou libcurl, a via indicada será a apresentação direta no repositório do GitHub do projeto, e convém documentar com clareza como reproduzir a falha e seu impacto. Para a comunidade em geral, o episódio serve como um lembrete de que a qualidade das comunicações técnicas é tão importante como a própria vulnerabilidade: um relatório bem redigido e verificável continua a ser a melhor forma de colaborar.

Daniel Stenberg anunciou que publicará um artigo mais detalhado sobre a mudança e as razões subjacentes; até então, as fontes primárias do movimento estão disponíveis publicamente e são a referência mais confiável para entender as nuances. Para consultar a política atual e o histórico do projeto, revisa o repositório oficial no GitHub e as entradas assinaladas anteriormente.