Imaginez la scène : une CVE classée Critique avec un score CVSS de 10.0 frappe SQLite, le moteur de base de données embarqué le plus déployé au monde. Vos outils de scanning remontent l’alerte, vos équipes priorisent le correctif. Sauf que la vulnérabilité n’existe tout simplement pas. C’est le constat que viennent de publier les chercheurs de JFrog Security Research : sur 55 CVE récentes visant SQLite et déposées en l’espace de quatre jours par un même dépôt GitHub, 54 étaient techniquement infondées. Ces fausses CVE SQLite générées par IA sont passées à travers toutes les mailles du filet, jusqu’à atterrir dans la National Vulnerability Database avec enrichissement de la CISA. Retour sur une affaire qui bouscule la gestion opérationnelle des vulnérabilités.
L’affaire SQLite : 54 fausses CVE sur 55 en quatre jours
Entre le 26 et le 30 juillet 2026, un dépôt GitHub fraîchement créé (programmervuln/cveadvisory) a publié 55 avis de vulnérabilité ciblant SQLite. En apparence, tout y était : descriptions techniques, scores CVSS élevés, PoC (preuves de concept) et références à des versions spécifiques du code source.
La NVD les a rapidement intégrées, avec un enrichissement fourni par la CISA en tant qu’Authorized Data Publisher (ADP). L’une d’elles, la CVE-2026-51302, s’est même vu attribuer un score CVSS de 10.0 (Critique) par Red Hat, avant d’être rétrogradée à 7.6 (Élevé) après vérification.
Le problème ? Quand les chercheurs JFrog ont voulu reproduire ces vulnérabilités, tout s’est effondré. Les fonctions citées dans les advisories n’existaient pas dans les versions incriminées. Les PoC ne déclenchaient aucun crash. Les correctifs évoqués étaient inventés de toutes pièces. Et aucun de ces 55 avis ne figurait sur la page officielle des CVE de SQLite, pourtant reconnue comme une référence fiable par la communauté.
Plongée dans le détail technique : des vulnérabilités fantômes
JFrog a mis en place une méthodologie de vérification rigoureuse : clonage du dépôt officiel SQLite, compilation en environnement isolé sous Docker, exécution des PoC avec instrumentation AddressSanitizer (ASan), et audit croisé des métadonnées NVD. Voici ce qui en est ressorti.
Des fonctions qui n’existaient tout simplement pas
La CVE-2026-51302 (score initial 9.8) prétendait décrire un use-after-free dans la fonction exprComputeOperands(). Problème : cette fonction n’existait pas dans SQLite 3.41.0, la version ciblée. Elle n’a été introduite qu’au milieu de l’année 2025, via les commits e24f20a et 280559b. La mécanique décrite impliquait sqlite3ReleaseTempReg(), une fonction qui recycle des indices de registres dans un tableau et ne réalise aucune désallocation mémoire. Un use-after-free était structurellement impossible.
Même schéma pour la CVE-2026-51297 (8.8) : la fonction jsonBlobEdit() était absente de la version 3.41.0. Elle n’est apparue que plus tard, dans le cadre de l’implémentation JSONB.
Des correctifs fantômes et des numéros de ligne impossibles
La CVE-2026-51303 affirmait qu’un correctif avait été appliqué dans la version 3.51.3 pour corriger une mauvaise gestion des back-references dans ExprListDelete(). Un diff entre les versions 3.51.2 et 3.51.3 n’a montré aucune modification du fichier src/expr.c. Le patch était purement fabriqué.
Plus flagrant encore : la CVE-2026-51296 (7.5) pointait les lignes 3555 et 3575 de json.c. Dans la version 3.41.0, ce fichier ne comptait que 2706 lignes. Les numéros cités dépassaient la fin du fichier.
La CVE-2026-51304, quant à elle, décrivait une signature de fonction à un seul argument qui n’a jamais existé dans le code source de SQLite. La véritable signature requiert un pointeur vers le contexte de base de données (sqlite3 *db), et le code réel neutralise immédiatement le pointeur après libération, rendant toute exploitation impossible.
Comment ces fausses CVE ont-elles franchi les mailles du filet ?
Le processus de soumission des CVE via le formulaire public de MITRE ne requiert aucune vérification d’identité sérieuse. N’importe qui peut soumettre une description de vulnérabilité et proposer un score CVSS. Historiquement, le NIST jouait un rôle de filet de sécurité : les experts de la NVD analysaient, validaient et enrichissaient manuellement les CVE entrantes avant de leur donner un sceau d’approbation.
Ce filet de sécurité s’est rompu en février 2024. Face à une explosion du volume de rapports de vulnérabilités, le NIST a mis en pause ses analyses approfondies. La CISA et d’autres ADP ont tenté de compenser avec leurs propres enrichissements, mais le pipeline mondial est aujourd’hui fragmenté et submergé par un arriéré massif.
Résultat : comme aucune étape du système actuel n’exige une preuve de concept fonctionnelle ou une reproduction du bug, un avis frauduleux bien rédigé peut traverser tout le pipeline et se retrouver dans les bases GHSA, les scanners d’entreprise et les outils de priorisation automatique.
Les signaux d’alerte pour repérer une CVE slop
L’épisode SQLite fournit une grille de lecture précieuse pour les équipes sécurité. Voici les drapeaux rouges identifiés par JFrog pour détecter une CVE générée par IA :
- Absence de corroboration éditeur : la vulnérabilité n’apparaît pas sur la page sécurité officielle du mainteneur. Pour SQLite, c’est sqlite.org/cves.html, une référence que JFrog qualifie de « gold standard ».
- Aucun hash de commit ni pull request : les champs de référence ne pointent vers aucun changement de code vérifiable dans le dépôt officiel.
- Contradictions dans les métadonnées : définitions CPE vides, plages de versions incompatibles avec le récit de l’advisory.
- Références à du code inexistant : fonctions absentes de la version ciblée, numéros de ligne dépassant la taille du fichier, signatures de fonctions erronées.
- Détection par des outils anti-IA : le regroupement des advisories dans un seul fichier a déclenché des alertes de contenu généré par IA sur des outils comme GPTZero.
Ces CVE slop ne sont pas anodines. Elles obligent les organisations à enquêter sur des vulnérabilités fantômes, à gaspiller du temps de recherche et, dans certains environnements où les vulnérabilités Critiques déclenchent automatiquement des tickets, à générer une charge opérationnelle bien réelle pour un risque inexistant.
Le risque est encore amplifié dans les organisations qui utilisent l’IA pour automatiser le triage et la remédiation des vulnérabilités. Un agent IA confronté à une fausse CVE peut tenter de localiser une fonction qui n’existe pas, générer un correctif inutile, ou recommander des modifications basées sur du code fantôme.
Ce qu’il faut retenir
- Sur 55 CVE SQLite publiées en quatre jours par un seul dépôt GitHub, 54 étaient fabriquées : fonctions inexistantes, correctifs inventés, PoC non fonctionnels.
- Ces fausses CVE, vraisemblablement générées par un LLM, ont atteint la NVD avec enrichissement CISA, prouvant que le pipeline de validation est aujourd’hui dépassé.
- Le score CVSS et la présence dans la NVD ne suffisent plus à garantir la légitimité d’une vulnérabilité.
- Validez systématiquement l’avis, le PoC et le code source avant de prioriser ou d’appliquer un correctif, surtout quand l’éditeur n’a rien publié.
- Les signaux d’alerte sont identifiables : absence de commit, métadonnées contradictoires, références à du code inexistant.
Cet épisode marque un tournant. La génération automatisée de fausses CVE par IA n’est plus une hypothèse, c’est un problème avéré. Si vous gérez des infrastructures où les correctifs sont déployés sur la base de scores CVSS, le moment est venu de muscler votre processus de vérification.
Vous avez rencontré des CVE douteuses dans vos environnements ? L’échange est toujours ouvert sur le blog ou sur les réseaux. Pensez aussi à vous abonner pour recevoir les prochains décryptages.
Sources
- JFrog Security Research : article original « SQLite Critical CVEs or LLM Slop? » par Afek Berger (30 juillet 2026), research.jfrog.com
- JFrog Security sur X : alerte publique du 29 juillet 2026
- The Register : couverture journalistique confirmant l’arrivée des fausses CVE dans la NVD avec enrichissement CISA
- SQLite Advisory Page : page officielle de référence sqlite.org/cves.html