Un dépôt GitHub fraîchement créé a publié une série d’avis sur de prétendues vulnérabilités critiques dans SQLite. NVD a attribué des scores CVSS jusqu’à 9.8, et l’ADP de CISA a confirmé la gravité. Quand les chercheurs de JFrog sont allés vérifier, les fonctions citées n’existaient pas dans les versions indiquées, les proof-of-concept ne provoquaient aucun crash, et les prétendus correctifs étaient inexistants. Les avis, traités par un détecteur de contenu IA, s’avèrent générés par un modèle de langage.

Pourquoi cela vous concerne. Les systèmes automatisés qui classifient les vulnérabilités ont traité ces faux comme s’ils étaient réels. Si votre pipeline CI/CD inclut des contrôles automatisés sur les CVE des dépendances, vous avez peut-être reçu des alertes sur des bugs inexistants. Les infrastructures critiques de sécurité ingèrent du contenu sans le vérifier, et ce contenu peut maintenant être généré par un LLM à un coût quasi nul.

Cela concerne ceux qui utilisent des agents IA pour automatiser l’analyse de sécurité. La même facilité avec laquelle un modèle rédige un avis crédible à première lecture est celle avec laquelle il produit n’importe quel résultat plausible mais faux. Une étape de vérification, même rapide, coûte moins qu’une fausse alerte qui déclenche un plan de réponse à incident sur une menace inexistante.

En détail

Le dépôt programmervuln/cveadvisory- a publié début août une vingtaine d’avis sur des vulnérabilités SQLite, plus une cinquantaine d’autres signalements que JFrog considère comme également générés par un LLM. La base de données nationale des vulnérabilités (NVD) a enregistré six de ces CVE avec des scores élevés : deux à 9.8 (critiques), une à 9.1, trois entre 7.5 et 8.8. L’Automated Decision Plugin (ADP) de CISA a validé les évaluations de gravité.

JFrog a suivi un protocole rigoureux pour vérifier chaque signalement : clone du dépôt officiel SQLite, extraction des versions citées (3.41.0, 3.51.2, 3.51.3), compilation dans des conteneurs isolés, et tests des proof-of-concept sous AddressSanitizer pour détecter les violations mémoire.

Les résultats sont sans équivoque. La CVE-2026-51302 (9.8 critique) cite la fonction exprComputeOperands() comme siège d’une use-after-free, mais cette fonction n’existait pas dans SQLite 3.41 : elle a été introduite en 2025. La fonction sqlite3ReleaseTempReg() mentionnée comme cause du dangling pointer n’alloue pas de mémoire heap : elle recycle des indices de registre dans un tableau, rendant une UAF impossible par construction.

La CVE-2026-51303 (9.8 critique) décrit un correctif dans la version 3.51.3 qui n’existe tout simplement pas. Le diff entre 3.51.2 et 3.51.3 ne montre aucune modification à src/expr.c. Le PoC associé est du SQL invalide et est rejeté par le parseur avant d’atteindre la logique d’exécution.

La CVE-2026-51300 (9.1 critique) cite des numéros de ligne spécifiques de expr.c qui correspondent à un commentaire et à un appel d’allocation, sans aucune relation avec la logique de suppression décrite. Le PoC, exécuté comme une requête valide, retourne le résultat attendu sans fuite mémoire.

Deux signaux confirment l’origine générative. JFrog a transmis les avis à GPTZero, qui les classe comme contenu IA. Et en combinant tous les avis dans un seul fichier, les détecteurs de contenu généré déclenchent des avertissements immédiats. Le dépôt semble être une expérience, ou une attaque coordonnée, où quelqu’un utilise un LLM pour produire des avis techniquement plausibles à première lecture et les soumet aux systèmes de suivi.

Ce qui change. Le pipeline de confiance des vulnérabilités fonctionne ainsi : quelqu’un publie un avis, NVD l’enregistre, CISA l’évalue, et les outils de dependency scanning le propagent aux développeurs. Jusqu’à présent, le goulot était la quantité d’avis humains. Avec un LLM, le goulot disparaît : vous pouvez générer des centaines de CVE crédibles à première lecture en une après-midi.

Red Hat avait initialement attribué à l’une de ces CVE un score 10.0, puis l’a abaissé à 7.6. Même les équipes de triage professionnelles, face à un avis bien construit, ont du mal à distinguer le vrai du faux sans plonger dans le code.

Ce qui reste ouvert. On ne sait pas qui se cache derrière le dépôt, ni si l’objectif était de tester les systèmes, créer du bruit pour en couvrir autre chose, ou prouver que c’est possible. JFrog a analysé six CVE en détail : les 50+ autres signalements du même dépôt restent à vérifier un par un. Et on ne sait pas combien d’outils de sécurité automatisés ont déjà alerté les développeurs sur ces fausses CVE, ni combien d’équipes ont redéployé des ressources pour répondre à des menaces inexistantes.