Le Centre national de cybersécurité néerlandais (NCSC) a passé cinq jours à demander aux organisations de s'inquiéter d'un bug qui n'a jamais existé. Le 29 juillet, le NCSC a publié l'avis NCSC-2026-0268, mettant en garde contre CVE-2026-51302, une faille de corruption de mémoire dans SQLite 3.41 assortie d'un score de gravité allant jusqu'à 10 sur 10. Lundi, l'agence a retiré l'avis en y ajoutant une seule ligne, indiquant que le CVE avait été retiré et que la vulnérabilité avait très probablement été hallucinée par un grand modèle de langage.

Le fil de l'affaire est documenté par l'équipe de recherche en sécurité de JFrog, qui a remonté la trace du CVE jusqu'à un compte GitHub nommé programmervuln, auteur de 55 avis de vulnérabilité concernant SQLite. L'audit de JFrog a établi que 54 étaient entièrement fabriqués et qu'un seul contenait un bug réel, enrobé de métadonnées CVE non vérifiées. Les fabrications n'avaient rien de subtil dès lors que quelqu'un y regardait vraiment. Les fonctions citées dans les avis n'existent pas dans les versions de SQLite mentionnées, les numéros de ligne référencés pointent au-delà de la fin des fichiers, les charges de démonstration n'ont rien fait planter lorsqu'elles ont été exécutées sous AddressSanitizer, et aucun des CVE ne figure sur la propre page de vulnérabilités de SQLite. Le texte lui-même a déclenché des alertes de l'outil de détection d'IA GPTZero.

Ce qui compte, c'est la distance parcourue par cette fiction avant que quiconque ne vérifie. Le formulaire public de soumission de CVE de MITRE n'effectue aucune véritable vérification d'identité, si bien que le compte a pu obtenir au moins six identifiants CVE, dont quatre classés critiques ou élevés, y compris deux notés 9,8 et un 9,1. NIST a réduit l'analyse manuelle des soumissions après une explosion de l'arriéré début 2024, ce qui a supprimé la couche qui aurait autrefois pu intercepter l'affaire. De là, les scores ont circulé automatiquement vers les bases de données que consomment les scanners de vulnérabilités, les vérificateurs de dépendances et les équipes nationales de réponse. Aux Pays-Bas, la chaîne s'est terminée par un avis gouvernemental demandant aux organisations d'appliquer des correctifs.

SQLite constitue une cible de pire scénario pour ce type de pollution, car il compte parmi les logiciels les plus largement déployés au monde, embarqué dans les navigateurs, les téléphones, les systèmes d'exploitation et d'innombrables applications. Un score critique à son encontre garantit l'attention. Les chercheurs de JFrog ont exposé le coût sans détour, écrivant que ces CVE de pacotille générés par LLM peuvent amener des organisations à perdre du temps à enquêter sur des vulnérabilités qui n'existent pas et à les corriger, tout en polluant les bases de données de vulnérabilités. Ce coût a été payé en heures bien réelles, par des équipes de sécurité qui ont trié les alertes et par une agence nationale qui a émis un avertissement avant de devoir faire machine arrière.

La rétractation elle-même est la partie saine de l'histoire, et les vérifications qui ont finalement démasqué la supercherie, lire le code source, exécuter l'exploit, consulter la page de sécurité de l'éditeur, sont précisément celles que la chaîne a sautées à l'entrée. L'asymétrie est le problème qui demeure. Un modèle de langage peut produire un avis convaincant en quelques secondes, tandis que le réfuter a demandé aux chercheurs des heures de vérification manuelle pour chaque affirmation. Le système CVE a été bâti sur l'hypothèse que les rapports de vulnérabilité sont soumis de bonne foi, et cette hypothèse doit désormais survivre au contact d'outils capables de fabriquer à grande échelle une fiction assurée et bien mise en forme.