Notée 10 sur 10, la note de sévérité maximale, la vulnérabilité avait tout d'une catastrophe. Elle visait SQLite, le moteur de base de données le plus déployé au monde — il tourne dans chaque smartphone, chaque navigateur, d'innombrables applications embarquées. Une faille critique dans SQLite, c'est potentiellement des milliards d'appareils exposés. La notification avait été validée par les bonnes autorités, reprise dans la base de référence du gouvernement américain, relayée par les agences de cybersécurité européennes. Un seul problème : la faille n'a jamais existé. Elle était l'invention d'une intelligence artificielle, et il aura fallu la ténacité du créateur de SQLite lui-même, épaulé par des chercheurs en sécurité, pour la faire disparaître des bases officielles.

Un dépôt GitHub, cinquante-cinq failles, une seule vraie

L'affaire remonte à un compte GitHub fraîchement créé, programmervuln, qui a déversé en quelques jours une cinquantaine de rapports de vulnérabilités. Six d'entre eux ciblaient SQLite, les autres visaient la bibliothèque de traitement d'images RAW libraw et un décodeur audio pour cartes Arduino, ESP32-audioI2S. Les scores annoncés allaient de 7,5 à 9,8 sur l'échelle CVSS, celle qui hiérarchise la gravité des vulnérabilités. L'une des entrées SQLite, une prétendue faille de type « use-after-free », a même décroché la note parfaite de 10,0, attribuée dans un premier temps par Red Hat avant d'être ramenée à 7,6.

C'est l'équipe de recherche en sécurité de JFrog qui a tiré le fil. En voulant vérifier ces alertes, ses chercheurs ont vu l'édifice s'effondrer. Sur les cinquante-cinq rapports publiés par le compte, cinquante-quatre étaient de pures fabrications ; un seul décrivait un vrai bug, noyé dans des métadonnées de CVE non vérifiées. Aucun des six rapports SQLite ne décrivait, selon JFrog, « une vulnérabilité reproductible ».

Les incohérences techniques ne trompaient pas un œil averti. La faille notée 10,0 renvoyait à une fonction du code, exprComputeOperands(), censée présenter le défaut — sauf que cette fonction n'existait pas dans la version 3.41 de SQLite visée. Elle n'a été ajoutée au code qu'au milieu de l'année 2025, un an après la version supposément vulnérable. Un autre rapport pointait un bug aux lignes 3555 et 3575 du fichier json.c ; or, dans la version 3.41.0, ce fichier ne comptait que 2706 lignes. Les codes d'exploitation (les « preuves de concept » censées démontrer l'attaque) ne déclenchaient aucun plantage lors des tests sous AddressSanitizer, l'outil de référence pour détecter ce genre de corruption mémoire. Passés au détecteur GPTZero, tous les avis du dépôt ressortaient comme générés par une IA.

Un pipeline qui carbure à la confiance

Comment un texte inventé de toutes pièces par un modèle de langage a-t-il pu remonter jusqu'à la National Vulnerability Database (NVD), le registre faisant autorité pour le gouvernement américain, avec en prime un enrichissement fourni par la CISA, l'agence fédérale de cybersécurité ? Parce que le système qui alimente les bases de vulnérabilités repose, pour l'essentiel, sur la confiance.

N'importe qui peut soumettre une description de vulnérabilité via le formulaire public du MITRE, l'organisme qui coordonne l'attribution des identifiants CVE, et proposer lui-même son score de gravité. Aucune vérification d'identité sérieuse n'est exigée, et surtout aucune étape de la chaîne n'impose de fournir un code d'exploitation fonctionnel ou une reproduction du bug. « Parce qu'aucune étape du système actuel n'exige réellement une preuve de concept ou une reproduction du bug, un avis bidon mais plausible peut se glisser directement dans le pipeline », résume JFrog.

Ce garde-fou a longtemps existé, pourtant. Le NIST, l'agence américaine des standards qui gère la NVD, faisait relire chaque fiche à la main par ses experts. Puis, début 2024, un afflux de soumissions a fait céder le dispositif : le NIST a suspendu son analyse approfondie. La file d'attente des CVE non traités a alors enflé — plus de 17 000 fin 2024, plus de 27 000 fin 2025, selon un rapport de l'inspecteur général du département du Commerce publié en mai 2026. Le contrôle humain qui aurait pu intercepter une invention grossière n'était tout simplement plus là.

L'obstination du créateur de SQLite

Face à ces failles fantômes, le créateur de SQLite, Richard Hipp, n'a pas ménagé sa peine pour les faire retirer — dans la lignée d'un combat qu'il mène depuis des années. Sur le forum du projet, Hipp explique de longue date le peu de cas qu'il fait de ces notifications : « Le contenu informatif des CVE est très faible, au point d'être inutile », écrivait-il déjà en 2020, à propos d'une précédente vague de CVE contestés. Il racontait aussi avoir tenté de faire entendre raison au NIST, en vain : « ils ne semblaient avoir aucun intérêt pour mes remarques concernant les CVE rédigés contre SQLite ».

Cette fois, l'insistance a payé, appuyée par le signalement formel de JFrog auprès de l'équipe de sécurité de GitHub (GHSA), de Red Hat et de la NVD. Tous ont fini par signaler ou retirer les fiches. Le MITRE, lui, a rejeté l'intégralité du lot du dépôt — une décision annoncée sur la liste de diffusion OSS-Security d'Openwall. La faille notée 10 sur 10 a été rétrogradée puis invalidée. Restait le paradoxe : il aura fallu des mois et l'obstination du principal intéressé pour effacer ce qu'une IA avait produit en quelques secondes.

Quand une IA écrit le bug qu'une autre IA veut corriger

L'épisode dépasse le cas SQLite. Il illustre un phénomène que les chercheurs commencent à baptiser « CVE slop » — le déchet généré par IA qui vient polluer les bases de vulnérabilités, cousin du « slopsquatting » qui consiste à peupler les dépôts de paquets logiciels hallucinés. Le risque n'est pas seulement de faire perdre du temps aux équipes de sécurité, sommées d'enquêter sur des trous qui n'existent pas. Il est plus retors quand on automatise la défense.

De plus en plus d'outils de sécurité s'appuient sur des agents IA pour corriger automatiquement les vulnérabilités signalées. Confrontés à une CVE fictive, ces agents peuvent aller modifier du code parfaitement sain pour « réparer » un problème imaginaire, introduisant au passage de vraies régressions. La boucle décrite par les observateurs a de quoi donner le vertige : « Une IA rédige un avis plausible, un pipeline en sous-effectif le laisse passer, et une autre IA tente de le corriger. »

La leçon rejoint un débat plus large sur les hallucinations des modèles de langage appliqués à la cybersécurité : la capacité de ces outils à produire du texte technique crédible dépasse aujourd'hui la capacité des chaînes de validation à en vérifier le fondement. Tant que rien n'obligera à joindre une preuve reproductible, le maillon faible restera le même — la confiance accordée par défaut à une description qui « sonne juste ». En attendant que les garde-fous s'adaptent, ce sont des développeurs comme Richard Hipp qui, à la main, font le tri entre les vraies failles et les mirages d'une machine.