CVE a été conçu pour suivre les failles de code avec des correctifs. Elle est désormais étendue pour couvrir les logiciels malveillants et les incidents de chaîne d’approvisionnement qui ne correspondent pas. C’est dans l’infrastructure des agents et les actifs d’IA que cette dérive devient structurelle.
Le 22 avril, pendant environ 90 minutes, une version malveillante de Bitwarden CLI est apparue sur npm. La version 2026.4.0 contenait une charge utile de vol d’informations d’identification qui exécutait un chargeur obscurci et récoltait des jetons AWS, Azure, GCP, GitHub et npm à partir de n’importe quelle machine de développeur exécutée. npm install. Les attaquants ont atteint le chemin de publication npm de Bitwarden via une action GitHub compromise liée à l’incident de la chaîne d’approvisionnement Checkmarx qui a affecté plusieurs autres consommateurs en aval cette semaine-là.
Environ neuf jours plus tard, Bitwarden a émis le CVE-2026-42994 pour la version trojanisée. Les défenseurs exécutant un outil d’analyse de la composition logicielle ont commencé à le voir sur leur tableau de bord. Les ingénieurs en détection ont commencé à rédiger des règles. L’incident a fait l’objet d’un article, d’une entrée dans le fil de renseignements sur les menaces de quelqu’un et d’une ligne dans les indicateurs du trimestre suivant.
Remarquez cependant ce que fait réellement CVE. Cela ne demande à personne de corriger une faille. La faille était une fenêtre de 90 minutes au cours de laquelle un pipeline de publication a été compromis, et la fenêtre s’est fermée. Le CVE est une notification rétroactive. Autrement dit, si tu courais npm install pendant cette fenêtre, traitez vos informations d’identification de développeur comme exposées. Il s’agit d’une réponse aux incidents, pas d’un suivi des vulnérabilités.
Il s’agit du système fonctionnant selon les normes 2026. C’est loin de ce pour quoi CVE a été conçu.
La dérive
CVE a été lancé en 1999 comme identifiant de vulnérabilité. La définition originale était stricte : une faille dans un système qui viole une politique de sécurité, avec un correctif que les défenseurs peuvent appliquer sur une plage de versions connue. Heartbleed dans OpenSSL 1.0.1f. Les failles de désérialisation dans Apache Struts. Corrigez la version, scannez pour vérifier, le tableau de bord devient vert.
MITRE et les CNA ont commencé à étendre le cadre presque immédiatement. L’incident SolarWinds de 2020 a obtenu le CVE-2020-10148, mais la « vulnérabilité » était une porte dérobée insérée dans une mise à jour signée, et non une faille de code écrite par le responsable. node-ipc/peacenotwar en 2022, j’ai obtenu CVE-2022-23812 pour les fichiers effacés en fonction de la géolocalisation. Dans les deux cas, le correctif consistait à « supprimer la mauvaise version », et non à apporter un correctif à un composant défectueux. L’identifiant fonctionnait toujours, mais il ne faisait plus le travail pour lequel il avait été conçu.
CVE suivait désormais plutôt que les défauts du code.
Des attaques comme la singularité et Shai-Hulud ont brisé le tronçon. Le ver npm auto-propagé qui est apparu en septembre 2025 et est revenu sous des variantes croissantes jusqu’en 2026 a infecté des centaines de paquets à travers l’écosystème. Certaines versions concernées ont obtenu des CVE, mais la plupart ne l’ont pas fait. L’avis de Red Hat sur la campagne reconnaît une évidence : « en raison du nombre sans précédent d’organisations et d’individus touchés, il est peu probable que tous les paquets infectés se voient attribuer des identifiants CVE ».
Il est intéressant de noter que le compromis Bitwarden de fin avril est lui-même une variante de Shai-Hulud, avec la chaîne « Shai-Hulud : The Third Coming » intégrée dans la charge utile malveillante. Il a obtenu un CVE car il s’agit d’un package identifiable avec une mauvaise version identifiable. Les plus de 700 packages des vagues précédentes de la même campagne ne l’ont pour la plupart pas fait.
Les fournisseurs réparent également les choses en silence, sans divulgation. Le rapport d’un chercheur est considéré comme informatif, le problème sera présenté dans la prochaine version comme une « amélioration de renforcement » ou, mieux encore, une « amélioration de la sécurité » (pas un correctif). Aucun CVE n’est demandé. Parfois, c’est raisonnable, pas toujours. Quoi qu’il en soit, aucun outil du défenseur ne le voit, et l’IA ne fait qu’empirer les choses.
Ce que font les agents dans tout ça
La catégorie qui brise le plus clairement le cadre est celle qui ne dispose d’aucun système d’identification existant.
Les compétences, les serveurs MCP et l’échafaudage plus large autour des agents IA possèdent plusieurs propriétés pour lesquelles le framework CVE n’a jamais été conçu. Ils mutent au moment de l’exécution. La charge utile opérationnelle est souvent une instruction en langage naturel qu’un agent lit et exécute, ce qui signifie que les actifs agents n’ont pas toujours des identités stables. Ils sont extraits des registres publics mais également partagés via Slack ou issus d’un dépôt qui semblait officiel il y a trois mois. Le préjudice ne correspond à aucune catégorie de faiblesse existante.
Par exemple, une compétence appelée derp sur le skills.sh le registre illustre le problème. Il ne contient aucun indicateur de malware traditionnel. Aucun appel réseau, blobs base64 ou chemin d’accès aux informations d’identification. Le SKILL.md demande à Claude de produire délibérément du code défectueux, puis de proposer des correctifs défectueux en boucle, tout en cachant le fait qu’il le fait. Un CVE n’a rien à signaler. Pas de corruption de mémoire, de contournement d’authentification ou de vecteur CVSS. Le mal, cependant, est réel – heures perdues, confiance érodée dans l’agent, facture gonflée pour le calcul/les jetons – mais il est . Un scanner recherchant des modèles malveillants ne le détectera pas.
derp est petit, mais les attaques structurellement identiques ne le sont pas. Dans mes recherches chez Manifold Security en avril, nous avons identifié la campagne ClawSwarm qui répertorie 30 compétences publiées par un seul auteur de ClawHub. Certains d’entre eux incluent des utilitaires tels que Cron Helper (903 téléchargements) et Agent Security (685 téléchargements) qui inscrivent discrètement l’agent IA de l’utilisateur dans un réseau tiers. Installez-en un et l’agent s’enregistre auprès d’un serveur externe, signale ses capacités, génère un portefeuille cryptographique Hedera, stocke les informations d’identification sur le disque et interroge les tâches toutes les quatre heures. Les compétences fonctionnent. Ils recrutent également l’agent dans l’économie de quelqu’un d’autre à l’insu de l’opérateur.
C’est quoi le CVE pour ça ? Ces compétences ne sont pas des logiciels malveillants au sens traditionnel du terme. Les appels HTTPS sont documentés. La génération de portefeuille utilise un SDK légitime. Il n’y a pas de shellcode à signaler ni de C2 connu à bloquer. Même si un registre retire la campagne, le même modèle peut réapparaître sous un auteur différent avec un nom de fichier différent en une semaine. Le modèle centré sur les artefacts n’a rien à retenir.
Les fournisseurs de modèles frontières sont confrontés à une variante du problème. Ils versionnent leurs versions (Sonnet 4.6, Opus 4.7, GPT-5.1, etc.) mais les correctifs de sécurité ne sont pas toujours prononcés dans les notes de version. La vulnérabilité qui a fonctionné sur le modèle d’hier et qui échoue sur celui d’aujourd’hui est regroupée dans une mise à jour de capacité ou de nouvelles « sauvegardes » sans aucun delta de sécurité annoncé, sans avis et souvent sans modification de version lorsque la modification concerne une invite ou un classificateur système plutôt que le modèle lui-même.
Une enquête universitaire récente portant sur 295 avis de sécurité GitHub faisant référence à des composants liés au LLM a révélé que les métadonnées CWE existantes capturent les défauts au niveau du code mais sous-représentent systématiquement l’exposition médiée par le modèle, les cas où la vulnérabilité est déclenchée ou amplifiée par le raisonnement du modèle plutôt que par une faille dans le code environnant. Comme le disent les auteurs : « Les métadonnées actuelles du GHSA manquent d’indicateurs structurés de l’implication du LLM, ce qui nécessite une classification manuelle pour identifier les modèles d’exposition médiés par un modèle. »
CVE-2025-68664 dans LangChain Core, une faille de désérialisation déclenchable via des métadonnées influencées par des invites, est un cas rare qui a réussi à pénétrer dans le système, mais la plupart ne le font pas. Une technique d’injection rapide qui permet à un attaquant d’exfiltrer les sorties d’appels d’outils d’un agent pourrait être corrigée lors du prochain point de contrôle du modèle, faire surface dans un document de recherche six mois plus tard et ne jamais apparaître sur aucun tableau de bord.
Les deux sont exploitables, mais un seul est suivi.
À quoi ressemble une couche de signal exploitable
CVE fait toujours son travail pour ce pour quoi il a été conçu. Mais les hypothèses sous-jacentes à ce cadre (identité stable, contenu fixe, divulgation coordonnée, avis des fournisseurs) ne tiennent pas compte d’une part significative et croissante de la surface d’attaque des agents.
Une couche de signal exploitable pour cette catégorie a probablement besoin de trois éléments qui manquent au système actuel.
- Des identifiants comportementaux plutôt que des identifiants d’artefacts: Si une compétence qui demande à un agent d’exfiltrer les variables d’environnement est supprimée et que la même instruction apparaît demain sous un auteur différent avec un nom de fichier différent, l’identifiant pertinent est le comportement, pas le SHA. L’empreinte digitale de ce que fait réellement un agent (quelles données circulent où, à quels services externes il s’inscrit, quel outil il appelle au nom d’un utilisateur) vous donne quelque chose de durable à suivre, même lorsque l’artefact en amont est éphémère.
- Transparence du registre pour les retraits: Lorsque npm supprime un paquet, il existe une trace écrite. Lorsqu’un registre de compétences supprime un éditeur, ce n’est souvent pas le cas. L’écosystème va mûrir sur ce front, mais les entreprises clientes devraient le faire pression maintenant plutôt que d’attendre.
- Divulgation responsable, mais pour les fournisseurs : Nous avons besoin d’une comptabilité honnête de la part des fournisseurs sur ce qu’ils réparent et expédient en silence, y compris les fournisseurs de modèles. Je ne suis pas optimiste quant à celui-ci à court terme. Les incitations commerciales vont dans le mauvais sens, et la pression des clients (et ensuite celle des chasseurs de primes de bogues) est ce qui tend à faire bouger les fournisseurs ici.
Le tableau de bord dont vous disposez a été conçu pour les menaces que vous avez rencontrées
Le système de suivi des vulnérabilités a été construit autour d’un modèle centré sur les artefacts. Il continue de faire tout son possible pour faire face aux menaces pour lesquelles il a été conçu. Le Bitwarden CVE a atterri sur les tableaux de bord de l’ensemble du secteur. Le prochain aussi.
Ce qui n’arrivera pas, c’est une compétence extraite d’un registre sans avis. Ou un modèle de point de contrôle qui résiste silencieusement à une injection rapide pour laquelle il tombait autrefois. Ou votre agent, déjà inscrit dans le réseau de quelqu’un d’autre parce qu’un SKILL.md je le lui ai dit.
Si vous exécutez un programme de sécurité en 2026, votre tableau de bord présente de plus en plus une image incomplète. Les choses qui vous attireront ne sont pas toujours celles qui s’y trouvent. Savoir ce que vos outils regardent réellement et ce qu’ils ont arrêté de regarder est le point de départ du travail.
