curl met fin à son programme de bug bounty face au flot de rapports IA de mauvaise qualité

Le projet curl, l’un des outils de ligne de commande les plus utilisés au monde, a annoncé la fin de son programme de bug bounty sur HackerOne à la fin du mois de janvier 2026. Cette décision fait suite à un déluge de rapports de vulnérabilités de basse qualité, générés en masse par l’intelligence artificielle. Ce revirement majeur dans la sécurité des logiciels libres soulève des questions cruciales sur l’impact de l’IA sur les processus de divulgation responsable.

Un programme de bug bounty au bord de la rupture

Le programme de bug bounty de curl, hébergé sur la plateforme HackerOne depuis 2019, visait à récompenser les chercheurs en sécurité qui identifient des vulnérabilités critiques dans curl et sa bibliothèque associée, libcurl. Cependant, l’augmentation exponentielle de rapports soumis en 2025 et début 2026 a mis à mal l’équipe de sécurité du projet. Daniel Stenberg, fondateur et développeur principal de curl, a expliqué que la situation est devenue insoutenable.

“Nous avons commencé la semaine en recevant sept problèmes HackerOne en moins de seize heures. Certains étaient de véritables bugs, et s’occuper de ce lot a pris un bon moment. Finalement, nous avons conclu qu’aucun d’eux n’identifiait une vulnérabilité, et nous comptons déjà vingt soumissions effectuées en 2026.” — Daniel Stenberg

La majorité de ces soumissions sont qualifiées de « slop » (déchets) par Stenberg : des rapports générés par IA qui semblent plausibles à première vue mais qui ne contiennent aucune information utile ou exploitable. Ces rapports consomment des ressources précieuses, détourner l’attention des véritables menaces et menacent la santé mentale des mainteneurs bénévoles d’un petit projet open source. Ce phénomène s’étend même aux systèmes de tickets d’entreprise, comme le montre l’attaque des plateformes Zendesk détournées pour des vagues de spam massives en 2026.

Comprendre le phénomène du « AI slop » dans la cybersécurité

Le « AI slop » désigne ce flot croissant de contenu généré par l’IA qui a l’air bien écrit mais qui manque fondamentalement de substance, de pertinence ou de valeur. Dans le contexte de la sécurité logicielle, cela se traduit par des rapports qui utilisent un jargon technique, citent des CVE (Common Vulnerabilities and Exposures) fictifs ou mal contextualisés, et proposent des « vulnérabilités » qui sont en réalité des erreurs de code normales ou des comportements non préjudiciables.

• Exemple concret sur le marché français : Un développeur d’une petite agence web à Lyon, utilisant curl pour des scripts d’automatisation, a témoigné avoir reçu lui-même des rapports non sollicités prétendant avoir trouvé des failles dans son implémentation. Ces rapports, clairement automatisés, tentaient de le rediriger vers des services de consultation payants.

L’IA générative, lorsqu’elle est utilisée sans supervision humaine pour produire des rapports de sécurité, peut facilement halluciner des vulnérabilités basées sur des patterns de code courants, créant ainsi un bruit de fond qui noie les signaux réels. Stenberg a noté que curl a connu une augmentation particulièrement forte des soumissions par rapport à d’autres projets open source hébergés sur HackerOne.

L’impact sur les projets open source et la divulgation responsable

La décision de curl n’est pas anodine. Elle reflète une tension croissante dans l’écosystème de la sécurité open source. Les programmes de bug bounty sont essentiels pour inciter les chercheurs éthiques à découvrir et signaler des vulnérabilités de manière responsable, avant qu’elles ne soient exploitées par des acteurs malveillants. Cette vigilance est d’autant plus cruciale que les ransomware et attaques de la chaîne d’approvisionnement ont établi des records inquiétants en 2025. En retirant toute incitation financière, curl espère décourager les soumissions de mauvaise foi.

Conséquences potentielles :

• Réduction du bruit : L’équipe de sécurité pourra se concentrer sur les soumissions directes via GitHub, qui nécessitent un investissement initial plus important de la part du chercheur.
• Risque de baisse des rapports légitimes : Certains chercheurs sérieux, motivés par la récompense, pourraient être moins enclins à passer du temps sur des rapports détaillés sans garantie de compensation.
• Modèle alternatif : Le projet s’appuiera davantage sur la communauté et les mainteneurs eux-mêmes pour la détection des vulnérabilités.

Stenberg a souligné que, bien que le retrait de HackerOne puisse ne pas arrêter complètement le flot de rapports « pourris », il était nécessaire pour la survie du projet et le bien-être de son équipe restreinte.

Le nouveau processus de signalement des vulnérabilités pour curl

À partir du 1er février 2026, le processus de signalement des vulnérabilités pour curl change radicalement. Voici les étapes concrètes pour les chercheurs en sécurité : **

1. Fin des soumissions via HackerOne : Le projet n’acceptera plus de nouveaux rapports sur la plateforme à compter du 31 janvier 2026. Les rapports en cours seront traités jusqu’à leur résolution.
2. Signalement direct sur GitHub : Les chercheurs devront désormais signaler les vulnérabilités directement via le dépôt GitHub de curl, en ouvrant un “issue” dédié. Cette méthode demande plus de rigueur, car le rapport est public dès le départ (sauf si marqué comme sensible).
3. Pas de récompense monétaire : Le projet ne propose plus aucune récompense pour les bugs signalés et n’aidera pas les chercheurs à obtenir des récompenses auprès de tierces parties.
4. Sanctions pour les mauvaises soumissions : Le fichier security.txt du projet a été mis à jour pour avertir que les personnes soumettant des rapports de mauvaise qualité (“crap”) seront bannies du projet et ridiculisées publiquement.

“L’objectif principal de la clôture du bounty est de supprimer l’incitation pour les gens de soumettre de la merde et des rapports non bien recherchés. Le torrent actuel de soumissions met une charge élevée sur l’équipe de sécurité de curl, et c’est une tentative de réduire le bruit.” — Daniel Stenberg

Tableau comparatif : Ancien vs Nouveau processus de signalement

Stratégies pour les chercheurs en sécurité en 2026

Face à cette évolution, les chercheurs doivent adapter leurs méthodes pour rester efficaces et respectés dans la communauté open source.

Meilleures pratiques pour un rapport de qualité :

• Pré-recherche approfondie : Avant de soumettre, analysez le code source, testez la vulnérabilité dans un environnement contrôlé et vérifiez qu’elle n’a pas déjà été signalée.
• Rédaction claire et structurée : Utilisez un langage précis, décrivez les étapes de reproduction, l’impact potentiel et proposez une correction si possible.
• Utilisation du canal approprié : Privilégiez les canaux de signalement officiels indiqués par le projet (ici, GitHub). Évitez les emails ou les messages directs non sollicités. En matière de sécurité personnelle, il est également recommandé de supprimer les mots de passe enregistrés dans Chrome et d’adopter des alternatives sécurisées pour 2025.
• Respect des règles du projet : Lisez attentivement le fichier SECURITY.md ou security.txt pour comprendre les attentes et les limites.

Exemple de mini-cas : Un chercheur identifie une vulnérabilité de type buffer overflow dans une fonction de curl. Au lieu de générer un rapport automatique, il : 1) Reproduit le bug dans un environnement sandbox, 2) Écrit un PoC (Proof of Concept) minimal, 3) Documente l’impact (risque de crash ou d’exécution de code à distance), 4) Soumet le tout via un issue GitHub bien formaté, en restant disponible pour les questions des mainteneurs.

L’avenir de la sécurité open source à l’ère de l’IA

La situation de curl n’est pas isolée. Elle annonce probablement une tendance plus large où les projets open source devront trouver un équilibre entre l’ouverture à la communauté et la protection contre le spam automatisé. Les plateformes de bug bounty comme HackerOne pourraient être contraintes d’adapter leurs modèles pour filtrer les soumissions de mauvaise qualité.

Perspectives pour 2026 et au-delà :

• Montée en puissance des outils de filtrage : Les plateformes et les projets pourront intégrer des outils d’IA pour analyser et trier les soumissions, en identifiant les patterns typiques du « slop ».
• Renforcement de la communauté : La confiance et la réputation deviendront des devises encore plus précieuses. Un chercheur connu pour des rapports de qualité aura plus de poids qu’un anonyme soumettant des rapports automatisés.
• Collaboration accrue : Les projets pourraient développer des programmes de mentorat pour aider les nouveaux chercheurs à produire des rapports utiles, réduisant ainsi le bruit.

Conclusion : Une décision nécessaire pour la pérennité

La fin du programme de bug bounty de curl est un signal d’alarme pour l’écosystème de la sécurité logicielle. Elle illustre comment une technologie prometteuse comme l’IA peut, lorsqu’elle est mal utilisée, entraver la sécurité qu’elle est censée améliorer. Pour un projet aussi fondamental que curl, protéger ses mainteneurs et garantir l’efficacité des processus de sécurité est primordial.

Cette décision n’est pas un retrait de la sécurité, mais une adaptation stratégique. En recentrant ses efforts sur des canaux de signalement plus qualitatifs, curl vise à renforcer la robustesse de son logiciel à l’ère du AI slop. Les chercheurs et les entreprises qui dépendent de curl doivent désormais ajuster leurs attentes et leurs méthodes de collaboration avec la communauté open source. La vigilance et la qualité prime sur la quantité.