CVE bidon générés par IA : comment trier vos alertes

Le 3 août 2026, l'équipe de recherche en sécurité de JFrog a publié un constat qui devrait changer la façon dont toute organisation technique lit son flux de vulnérabilités. Un lot de six CVE SQLite classés critiques et élevés — dont un que Red Hat avait initialement noté à un CVSS parfait de 10.0 — s'est révélé être une fiction. Ni exagéré, ni contesté. Fabriqué.

Les avis citaient des fonctions qui n'existaient pas dans les versions affectées. Ils pointaient vers des numéros de ligne qui tombaient sur des commentaires. Ils référençaient des correctifs sans aucun diff correspondant. Et quand JFrog a remonté la piste, les six provenaient d'un unique dépôt GitHub créé récemment, qui avait publié 55 avis en quatre jours. 54 étaient entièrement fabriqués.

SQLite tourne dans chaque téléphone Android, chaque appareil iOS, chaque navigateur et la plupart des systèmes embarqués de la planète. Pendant environ une semaine, les équipes sécurité du monde entier ont eu six critiques fantômes dans leur file d'attente, visant l'un des logiciels les plus déployés jamais écrits.

C'est la partie de l'histoire IA et sécurité que personne n'avait anticipée.

Ce que JFrog a réellement trouvé

Les six avis n'étaient pas subtilement faux. Chacun s'effondrait dès qu'on ouvrait le code source.

Arrêtons-nous sur CVE-2026-51296. L'avis référençait la ligne 3555 d'un fichier de 2706 lignes. Cette seule vérification — le fichier a-t-il seulement autant de lignes ? — prend une dizaine de secondes et invalide un avis "haute sévérité". Personne dans la chaîne ne l'a effectuée avant que le CVE soit publié et répliqué dans les bases de données en aval.

Les preuves de concept fournies ne reproduisaient rien. Les scores de sévérité étaient confiants, précis, et rattachés à néant.

Pourquoi c'est structurellement différent d'un mauvais rapport ordinaire

Les faux rapports de vulnérabilité ne datent pas d'hier. Ce qui est nouveau, c'est l'asymétrie des coûts.

Produire un avis crédible exigeait auparavant une compréhension du code suffisante pour être dangereuse. Aujourd'hui, cela exige un prompt. Un LLM produira volontiers un avis techniquement fluide — terminologie correcte, noms de fonctions plausibles, mapping CWE, vecteur CVSS, preuve de concept convaincante à la lecture — pour un logiciel qu'il n'a jamais analysé, seulement reconnu par motifs. Le résultat est indiscernable d'un travail d'expert au premier coup d'œil, et sans valeur à l'inspection.

L'économie s'est inversée. Générer du bruit est désormais quasi gratuit ; le vérifier coûte toujours un après-midi d'expert. Cet écart est tout le problème, et c'est pourquoi cela ressemble moins à du spam qu'à une attaque par déni de service sur l'attention des mainteneurs.

Le projet curl a heurté ce mur en premier. Daniel Stenberg a retiré la récompense monétaire de curl début 2026, après un pic de volume d'environ huit fois, dont près d'un cinquième décrivait des vulnérabilités qui n'existaient tout simplement pas. Supprimer la prime a fonctionné — Stenberg a rapporté ensuite que "le problème du slop n'en est plus un", et que le taux de vulnérabilités confirmées est remonté au-dessus des niveaux d'avant 2024 une fois les chasseurs de primes partis. Linus Torvalds a décrit la liste sécurité du noyau comme quasi ingérable, en soulignant l'effet secondaire évident : "Si vous avez trouvé un bug avec des outils IA, il y a de fortes chances que quelqu'un d'autre l'ait trouvé aussi." Des doublons issus d'outils identiques, à grande échelle.

Et il n'y a pas que les faux rapports. Le suivi de VulnCheck sur le début 2026 montre que le volume de divulgations légitimes assistées par IA grimpe aussi fortement — Chrome en hausse de 563 %, les avis GitHub sur l'open source de 476 %, Apache de 170 %. Madison Oliver Ficorilli, chez GitHub, note qu'aucun rapporteur ne représente plus d'environ 3 % du volume et aucun projet plus d'environ 7 % — ce qui écarte l'hypothèse d'une poignée d'acteurs malveillants et pointe vers un phénomène systémique.

Votre flux reçoit donc deux inondations simultanées : plus de vulnérabilités réelles que votre équipe n'en a jamais traité, mêlées à des fabrications au format identique et aux scores de sévérité plus élevés. Les trier est devenu une compétence d'ingénierie de base.

La checklist de triage

Les signaux d'alerte de JFrog se généralisent en une vérification exécutable en quelques minutes, avant qu'un CVE critique ne réorganise la semaine de quelqu'un.

1. Consultez d'abord la page d'avis officielle du projet. SQLite maintient sqlite.org/cves.html. La plupart des projets sérieux publient un équivalent. Un CVE critique que les mainteneurs n'ont jamais reconnu est le signal le plus fort disponible, et il coûte un chargement de page.

2. Exigez un hash de commit ou une pull request. Tout correctif réel a un patch. Si l'avis dit "corrigé en 3.51.3" sans pouvoir désigner le commit, demandez pourquoi. Puis vérifiez le diff vous-même — git log -p v3.51.2..v3.51.3 -- src/expr.c aurait éliminé CVE-2026-51303 d'emblée.

3. Vérifiez que le code existe. Clonez la version affectée exacte et cherchez la fonction nommée dans l'avis. Si elle n'y est pas, c'est terminé. Cette vérification attrape la majorité des fabrications, car les LLM hallucinent des noms de symboles depuis des versions voisines et des idiomes C génériques.

4. Contrôlez les numéros de ligne. Le test le moins cher du lot. Un wc -l sur le fichier cité. Si l'avis pointe au-delà de la fin du fichier, arrêtez de lire.

5. Reproduisez la PoC en bac à sable. Si une charge utile est fournie, exécutez-la dans un conteneur isolé contre la version revendiquée. Pas de reproduction, pas de priorité. Non négociable pour tout ce qui est classé critique.

6. Examinez la cohérence des métadonnées. Définitions CPE vides, plages de versions affectées contradictoires, compte rapporteur tout neuf avec une rafale d'avis, plusieurs critiques déposés contre le même projet en quelques heures — signaux faibles isolément, décisifs ensemble.

7. Pondérez selon la source. Un CVE émis par l'équipe sécurité d'un projet, un éditeur connu ou un groupe de recherche établi n'est pas le même artefact qu'un CVE venant d'un compte créé la semaine dernière. Traitez la provenance du rapporteur comme un champ de premier ordre dans votre triage.

Voici un garde-fou sommaire à intégrer dans un script de revue :

#!/usr/bin/env bash
# Contrôle structurel rapide d'une affirmation de CVE.
# Usage : ./cve-check.sh <chemin-depot> <tag-version> <nom-fonction> <fichier> <ligne>
 
REPO=$1; TAG=$2; FUNC=$3; FILE=$4; LINE=$5
 
git -C "$REPO" checkout --quiet "$TAG" || { echo "FAIL: version tag $TAG not found"; exit 1; }
 
if ! grep -rq "\b$FUNC\b" "$REPO/$FILE"; then
  echo "RED FLAG: function '$FUNC' absent from $FILE at $TAG"
fi
 
TOTAL=$(wc -l < "$REPO/$FILE")
if [ "$LINE" -gt "$TOTAL" ]; then
  echo "RED FLAG: cited line $LINE exceeds file length ($TOTAL lines)"
fi
 
echo "Context at $FILE:$LINE —"
sed -n "$((LINE-2)),$((LINE+2))p" "$REPO/$FILE" 2>/dev/null

Trois vérifications, quelques secondes, et cela aurait signalé à lui seul quatre des six avis SQLite.

Ce qu'il faut changer dans votre processus

Les vérifications individuelles sont nécessaires mais insuffisantes. L'hypothèse de processus qui a cédé, c'est "CVE publié égale CVE vérifié". Cela n'a jamais été formellement vrai, mais c'était opérationnellement assez fiable pour bâtir des workflows dessus. Ce n'est plus le cas.

Trois ajustements valent la peine dès maintenant.

Insérez une étape de vérification entre l'ingestion et la priorisation. La plupart des équipes branchent un scanner directement sur une file de tickets, où le score CVSS fixe l'urgence. Ajoutez une étape : pour tout ce qui est noté 9.0 ou plus, un humain confirme que la vulnérabilité existe dans votre version réellement déployée avant qu'elle ne réveille qui que ce soit. Oui, cela ajoute de la latence sur les vrais critiques. L'alternative, c'est que n'importe qui muni d'une clé d'API puisse fixer les priorités de votre sprint.

Tracez la provenance du rapporteur dans votre outillage. Si votre plateforme de gestion des vulnérabilités n'affiche pas qui a déposé un avis et quand le compte a été créé, c'est une lacune à combler. Le lot SQLite était identifiable comme grappe — 55 avis, quatre jours, un dépôt neuf — bien avant que quiconque ne lise une ligne de C.

Formalisez votre procédure de CVE contesté. Quand vous établissez qu'un avis est invalide, quelqu'un doit le signaler à la CNA et aux bases en aval, et votre registre interne doit indiquer "vérifié faux" plutôt que "non corrigé". Sinon le même fantôme resurgit au prochain audit, et vos preuves de conformité pourrissent en silence. JFrog a signalé ses conclusions à GHSA, Red Hat et NVD — c'est cette étape qui retire effectivement la pollution.

Et si vous faites tourner des agents IA qui consomment des flux de sécurité et ouvrent automatiquement des PR de remédiation, cela vous concerne doublement. Un agent qui fait confiance aux scores CVSS brûlera du temps d'ingénierie réel à corriger des bugs imaginaires, et les correctifs auront l'air plausibles eux aussi. Toute boucle de remédiation automatisée doit intégrer le contrôle d'existence en amont de l'étape de correction — la même discipline que nous avons couverte dans le reward hacking et le detournement de spécification, appliquée aux entrées plutôt qu'aux sorties.

La symétrie inconfortable

La même capacité coupe dans les deux sens, et c'est ce qui rend le sujet difficile à réguler.

La recherche de vulnérabilités assistée par IA trouve de vrais bugs sérieux — le travail d'Anthropic sur Project Glasswing et la vague de divulgations légitimes de Mozilla, Microsoft et Google sont bien réels, et nous avons couvert ce versant dans Claude Mythos et Project Glasswing. Personne de sensé ne souhaite que cela s'arrête. Apache a reçu un don de 1,5 M$ précisément pour absorber la charge de réponse légitime accrue. Le mainteneur de curl a lui-même noté qu'une des cinq premières trouvailles de Mythos était valide — un taux de 20 % qui serait excellent pour un chercheur humain.

Le problème, c'est que le valide et le fabriqué arrivent dans la même enveloppe, au format identique, et que le fabriqué revendique généralement une sévérité plus élevée puisque rien ne le contraint. Il n'y a pas de filigrane, et les propositions de filtrer le slop IA avec de l'IA déplacent le problème de confiance plus qu'elles ne le résolvent.

Il reste une approche peu glorieuse mais efficace : reproduire avant de prioriser, et traiter un score de sévérité comme une affirmation plutôt qu'une mesure. Les dix secondes nécessaires pour lancer wc -l sur un fichier source constituent aujourd'hui l'une des pratiques de sécurité au meilleur rapport effort/effet.

Pour les équipes de la région

Pour les PME en Tunisie, en Arabie saoudite et plus largement dans la région MENA, cela retombe sur des capacités sécurité déjà minces. Si votre posture de conformité repose sur un rapport de scanner automatisé — et c'est le cas pour bien des organisations visant l'ISO 27001 ou des exigences proches de la ZATCA — vous avez désormais un problème de qualité de données sous vos preuves.

Le minimum praticable : aucun CVE critique n'atteint votre file de remédiation sans qu'un humain confirme que le chemin de code affecté existe dans votre déploiement. C'est une case dans un document de procédure et peut-être une heure par mois d'un ingénieur senior. C'est nettement moins cher qu'un trimestre passé à corriger un logiciel qui n'a jamais été cassé, et bien moins cher encore que le mode de défaillance alternatif — une équipe qui apprend à ignorer les critiques parce que la plupart se sont révélés du bruit.

Ce second scénario est le vrai risque ici. La fatigue d'alerte, c'est ainsi qu'un authentique CVSS 10.0 passe à travers.

Lectures associées :

• Claude Mythos et Project Glasswing : découverte de zero-days par IA
• Sécurité du code généré par IA : guide des vulnérabilités
• Trapdoor : attaque de la chaîne d'approvisionnement des outils de codage IA
• DevSecOps : sécurité intégrée au cycle de développement