Morgan Dutemple
← Retour au blog
IA

L'IA a tué le bug bounty de curl : quand les rapports de vulnérabilités deviennent du bruit

homme submergé de post-it à son bureau
Photo par Luis Villasmil sur Unsplash
Morgan Dutemple
·Delivery Manager & Expert Transformation Digitale

BentoPDF, outil open source de manipulation de PDF suivi par 14 400 personnes sur GitHub, a publié le 28 juillet 2026 sa version 2.8.7. Elle corrige trois vraies failles de sécurité (référencées GHSA-wh78-rcw2-hhg9, GHSA-5xjf-rr5x-pcfj et GHSA-cx8x-7rrr-r9x8), dont les détails techniques restent embargués le temps de la divulgation coordonnée. Rien d'inhabituel jusque-là.

Ce qui l'est moins : dans la même note de version, le mainteneur consacre presque autant de place à un autre sujet, la multiplication des signalements de vulnérabilités générés par IA, qu'il juge peu rigoureux, et il demande aux personnes qui contribuent de vérifier leurs trouvailles avant de les soumettre. Ce n'est pas un mainteneur isolé qui râle. C'est un symptôme d'un problème bien plus large, documenté depuis 2025 sur des projets autrement plus centraux que BentoPDF.

curl a fermé son bug bounty à cause de ça

curl, la bibliothèque de transfert de données qui équipe une bonne partie d'internet, publiait depuis des années un taux de rapports confirmés comme vulnérabilités réelles supérieur à 15%. En 2025, ce taux est tombé sous les 5%, submergé par des rapports générés par IA qui ont l'air plausibles en surface mais ne tiennent pas devant une vérification.

Daniel Stenberg, créateur et mainteneur principal de curl, a fini par fermer le programme de bug bounty fin janvier 2026 : plus aucune soumission via HackerOne n'est acceptée depuis le 1er février, les signalements de sécurité passent désormais directement par GitHub. Sa justification tient en une phrase : « the mind-numbing AI slop, humans doing worse than ever and the apparent will to poke holes rather than to help », trois mauvaises tendances qui se cumulaient plutôt qu'un seul problème isolé.

Node.js a dû durcir ses conditions plutôt que fermer le sien

Node.js n'a pas fermé son programme, mais a dû le blinder. Plus de 30 rapports invalides reçus entre le 15 décembre et le 15 janvier, sur la seule période des fêtes, ont précipité l'ajout d'une exigence de score Signal HackerOne d'au moins 1.0 pour pouvoir soumettre un rapport, au premier trimestre 2026.

Ça n'a pas suffi à endiguer la vague. En février 2026, les signalements ont été multipliés par 4,6 après l'arrivée d'outils de scan assistés par des agents IA, puis mars a vu passer 65 rapports en un seul mois, avec des formulations remarquablement similaires d'un rapport à l'autre, ce qui suggère la même génération LLM ou un outillage très proche derrière beaucoup d'entre eux. Node.js a aussi ajouté une exigence d'exemple reproductible en JavaScript (les rapports en Python ou dans un autre langage devaient auparavant être traduits par les mainteneurs avant même de pouvoir être triés), et explore désormais un triage assisté par IA : un classifieur à base de règles pour écarter le bruit évident, puis un LLM pour évaluer ce qui mérite vraiment une attention humaine.

Un problème sans détecteur fiable

Ce qui rend la situation difficile à traiter, ce n'est pas seulement le volume. C'est qu'il n'existe aucun indicateur technique fiable pour repérer un contenu généré par IA : la plupart des mainteneurs tranchent au feeling, sur la base de formulations trop lisses ou de détails qui ne collent pas au code réel. Chaque rapport à trier consomme du temps de relecture bénévole, qu'il soit vrai ou faux, et cette charge ne baisse pas avec le volume, elle grimpe avec lui.

Le groupe de travail sur la divulgation des vulnérabilités de l'OpenSSF (Open Source Security Foundation) a ouvert un chantier dédié pour tenter de construire des pratiques de référence face à ce qu'il appelle lui-même l'« AI slop » : modèles de politique de signalement, critères pour aider un mainteneur à repérer une soumission suspecte, recommandations sur la manière d'y répondre sans épuiser le temps bénévole disponible. Rien n'est stabilisé à ce stade, ce qui explique pourquoi chaque projet, curl, Node.js, BentoPDF, improvise sa propre parade en attendant.

Ce que ça change, concrètement

Le motif qui revient à chaque fois est le même : un canal ouvert pour recevoir des signalements de sécurité de bonne foi devient, à mesure que générer un rapport plausible ne coûte presque plus rien, un canal qu'il faut filtrer avant de pouvoir s'en servir. curl a choisi de fermer l'entrée. Node.js a choisi de la rendre plus étroite (score minimum, format imposé) plutôt que de la fermer. BentoPDF, plus petit, se contente pour l'instant d'un rappel dans sa note de version. Trois réponses différentes au même problème, à des échelles différentes.

Sources : BentoPDF v2.8.7 ; The end of the curl bug-bounty, Daniel Stenberg ; Node.js, New HackerOne Signal Requirement for Vulnerability Reports ; OpenSSF, AI-SLOP: Develop best current practises for Open Source maintainers.

Questions fréquentes

Qu'est-ce qu'un rapport de vulnérabilité « AI slop » ?

Un signalement de faille de sécurité généré ou largement assisté par une IA, dont le contenu semble crédible en première lecture (vocabulaire technique, structure d'un vrai rapport) mais ne résiste pas à une vérification : la faille décrite n'existe pas, ou le code cité ne correspond pas au projet réel.

Pourquoi ces rapports ont-ils explosé en 2025-2026 plutôt qu'avant ?

Parce que des outils de scan assistés par des agents IA permettent de générer des rapports en masse à un coût quasi nul pour qui les soumet, alors que les vérifier reste un travail humain, non automatisable, pour le mainteneur qui les reçoit. Le déséquilibre entre coût de production et coût de vérification est la cause structurelle du problème.

Existe-t-il un moyen fiable de détecter un rapport généré par IA ?

Non, à ce jour. Les mainteneurs s'appuient sur leur expérience et des signaux indirects (formulations trop lisses, détails qui ne collent pas au code), pas sur un outil de détection validé. C'est précisément ce que le groupe de travail de l'OpenSSF tente de formaliser.

Morgan Dutemple

À propos de l'auteur

Morgan Dutemple

Delivery Manager à Rennes. Je pilote des projets de transformation digitale, SEO/GEO et accessibilité RGAA pour des clients grands comptes. Ce blog est le reflet de ce que je rencontre sur le terrain.