CVE fictives, rapports générés par l’IA et nécessité de vérification

Il devient moins coûteux de créer des rapports de vulnérabilité convaincants, ce qui accroît les conséquences pour les responsables de la maintenance des logiciels et les équipes de sécurité. Six vulnérabilités et expositions communes (CVE) visant SQLite ont été publiées en juillet 2026, et deux d’entre elles ont reçu un score de gravité de 9,8. Les rapports semblaient légitimes : ils décrivaient des problèmes de sécurité de la mémoire et comprenaient des explications techniques ainsi que du code de preuve de concept.

Mais les chercheurs de JFrog ont découvert que certaines des fonctions mentionnées dans ces rapports n’existaient pas dans les versions concernées. De plus, aucune des preuves de concept (PoC) ne reproduisait les vulnérabilités alléguées. La page CVE de SQLite indique actuellement que ces six signalements ne correspondent pas à des bogues ; les fiches CVE ont ensuite été rejetées.

Le problème ne se limite pas à SQLite. Daniel Stenberg, le responsable de la maintenance de curl, estimait l’an dernier qu’environ 20 % des signalements de sécurité reçus étaient le fruit de contenus médiocres générés par l’IA. L’autorité de numérotation CVE (CNA) de GitHub a reçu près de 4 000 demandes de CVE en mai 2026, soit une hausse du volume d’environ 10 fois par rapport à l’année précédente. GitHub n’a pas attribué cette hausse à l’IA ni fait état d’une baisse de la qualité des soumissions, mais cette forte augmentation du volume souligne la saturation du processus de divulgation des vulnérabilités.

L’IA facilite la création d’allégations détaillées de vulnérabilité, mais déterminer si elles sont légitimes prend du temps. Et lorsqu’une CVE est intégrée aux flux de sécurité et aux bases de données publiques, la correction de la fiche d’origine ne garantit pas que toutes ses copies seront corrigées. Il devient donc de plus en plus nécessaire de distinguer une vulnérabilité signalée d’une vulnérabilité vérifiée sur le plan technique.

Qu’est-ce qu’une CVE « fictive » ?

On emploie couramment l’expression « CVE fictive » pour désigner une CVE qui a probablement été signalée à tort. Mais « fictive » ne signifie pas qu’elle vise à induire délibérément en erreur. Elle peut résulter d’une analyse statique qui ne détecte pas un contrôle de validation ou qui interprète à tort une entrée comme étant contrôlée par un attaquant. Un rapport peut décrire une fonction réelle tout en alléguant un vecteur d’attaque invalide. Un identifiant (ID CVE) peut être attribué, puis retiré si le problème signalé ne constituait pas, en réalité, une vulnérabilité. C’est différent d’un rapport délibérément inventé.

Un désaccord ne constitue pas non plus une CVE fictive. Un fournisseur peut contester les conclusions d’un chercheur concernant la possibilité d’exploitation, les limites de la menace ou le fait qu’une fonction soit conçue ou non pour traiter des données non fiables. Mais un désaccord ne prouve pas que le chercheur s’est trompé. Et le rejet d’une CVE ne signifie pas nécessairement qu’elle a été fabriquée : elle peut être rejetée parce qu’elle fait doublon ou pour des raisons administratives. Même si un identifiant CVE ne constitue pas une vérification technique indépendante, le secteur doit prendre au sérieux les signalements crédibles.

Pourquoi les CVE fictives posent problème

L’un des problèmes que nous constatons est que des personnes utilisent l’IA pour générer des rapports de vulnérabilité sans vérifier correctement leurs conclusions. Ces rapports peuvent contenir des explications techniques détaillées, des références au code et même des preuves de concept, ce qui peut leur donner une apparence légitime. Mais, comme l’ont montré les CVE concernant SQLite, certaines des fonctions mentionnées n’existaient même pas dans les versions concernées.

GitHub a fait état d’une forte hausse des soumissions de vulnérabilités en 2026, sans toutefois l’attribuer à l’IA ni signaler de baisse de leur qualité. Le problème, c’est que plus le nombre de rapports augmente, plus le travail nécessaire pour les examiner s’alourdit, que les conclusions soient fondées ou non.

Toute personne ayant déjà trié des rapports de vulnérabilité connaît bien la difficulté pratique de la tâche. Un modèle d’IA peut repérer un appel d’API suspect, ébaucher un scénario d’exploitation et produire rapidement un rapport à l’apparence professionnelle. Pour déterminer si ce scénario est viable, il peut être nécessaire de vérifier la version exacte, de suivre le flux de contrôle, de comprendre comment les données parviennent à la fonction, de créer un environnement de test et d’exécuter l’exploit allégué. La démarche est la même, que le rapport soit exact ou non, et elle peut coûter cher.

Les CVE fictives peuvent aussi nuire à la réputation. Une annonce de vulnérabilité peut rapidement se diffuser dans les flux des outils d’analyse, les bases de données de sécurité et les résultats de recherche. En revanche, une correction ultérieure ne se propage pas forcément aussi loin. Même après qu’un rapport a été contesté ou rejeté, les fournisseurs peuvent devoir se justifier auprès de clients qui ont vu le signalement initial.

Il existe également un risque que de véritables vulnérabilités passent inaperçues ou soient traitées tardivement parce que les équipes consacrent du temps à examiner des signalements erronés. Lorsque les responsables de la maintenance et les équipes de sécurité disposent de ressources limitées, chaque heure passée à réfuter un faux positif est une heure qui aurait pu être consacrée à l’examen d’un véritable problème de sécurité.

Automatiser la riposte

De nombreux enquêteurs continuent de trier manuellement les rapports pour faire face à leur afflux croissant, mais cette méthode n’est pas viable. L’automatisation se révèle très utile pour vérifier une allégation de vulnérabilité au regard de la version et de la configuration réellement concernées. Voici les cinq questions à poser :

• Les conditions préalables à l’attaque sont-elles crédibles, notamment en ce qui concerne la configuration et les autorisations ?
• La fonction présumée existe-t-elle dans la version concernée ?
• Un attaquant peut-il atteindre le code vulnérable ? Déterminez si le code concerné peut s’exécuter dans les conditions affectées et si un attaquant peut fournir des données qui l’atteignent.
• Les testeurs peuvent-ils reproduire le comportement dans un environnement de test contrôlé ou à l’aide d’une preuve de concept (PoC) ?
• Le comportement observé produit-il l’impact sur la sécurité décrit dans l’avis ?

Les outils d’IA agentique peuvent créer des environnements de test, analyser les chemins d’exécution du code, générer des preuves de concept (PoC) et consigner des preuves d’exécution à examiner. Ils ne peuvent pas résoudre automatiquement toutes les affirmations. Même lorsqu’une vulnérabilité est authentique, une PoC peut échouer si l’environnement est incomplet ou si le déclencheur est incorrect. Les testeurs peuvent reproduire un plantage sans démontrer l’exploitabilité alléguée. Ces réserves expliquent pourquoi le jugement humain reste crucial. Toutefois, ces outils peuvent aider les équipes à se rapprocher d’une réponse reproductible avant qu’un rapport ne mobilise encore plus de temps au sein des équipes d’ingénierie, de gestion des vulnérabilités et d’assistance clientèle.

Réduire la surcharge dans l’écosystème des CVE

Aucune politique concise ne résoudra miraculeusement le problème des fausses CVE. Il serait toutefois utile d’exiger des éléments probants plus solides à l’appui des soumissions et de clarifier le statut de reproduction. Il serait également utile de mieux définir le traitement des enregistrements contestés et de corriger plus rapidement les données en aval. Les chercheurs devraient être encouragés à valider leurs résultats obtenus avec l’aide de l’IA avant de les soumettre.

Les équipes de sécurité et les fournisseurs doivent se concentrer sur l’examen des preuves. Une cote CVE critique n’indique pas si un chemin vulnérable est accessible dans leur environnement. L’échec d’une PoC ne signifie pas pour autant que tout va bien. Par ailleurs, l’attribution d’un identifiant CVE ne dispense pas les équipes d’effectuer le travail technique nécessaire pour comprendre un problème.

L’IA améliore les capacités de découverte des vulnérabilités, mais elle permet aussi de formuler des affirmations convaincantes en apparence, mais erronées. Face à la multiplication des rapports, les organisations doivent investir dans la vérification. Celle-ci consiste à élaborer des tests, à reproduire les résultats, à vérifier les hypothèses et à faciliter l’évaluation des preuves. Les tests de sécurité faisant appel à des agents pourraient jouer un rôle important dans ce domaine.