Les agents de codage IA sont désormais un vecteur d'attaque de la chaîne d'approvisionnement

Le 8 octobre 2026, un package npm nommé tensorlake a été publié avec une attestation de provenance valide. L’attestation était exacte. Le package était un malware, et il venait de voler les tokens GitHub, les clés cloud, les secrets Kubernetes et les clés SSH sur les machines de tous ceux qui l’avaient installé.

Votre politique de chaîne d’approvisionnement promet probablement quelque chose de rassurant. Installez les packages avec provenance. Faites confiance aux versions signées. Fiez-vous à la réputation du mainteneur. Tous ces contrôles ont fonctionné parfaitement le 8 octobre, et le malware est arrivé quand même.

Ce qui s’est réellement passé

Le premier commit malveillant a atterri sur main de tensorlakeai/tensorlake à 01

L’installation a déclenché le hook preinstall, qui a récupéré le runtime Bun et exécuté une charge utile obfusquée de 856 KB. La charge utile écartait les environnements CI : les postes de développement étaient la cible. Elle a collecté les tokens GitHub et npm, les identifiants cloud, les secrets Kubernetes et Vault, les clés SSH, les identifiants de navigateur enregistrés et les fichiers de configuration que des outils d’IA comme Claude, Cursor et Windsurf conservent sur disque. Elle a ensuite écrit .claude/settings.json et .vscode/tasks.json dans chaque dépôt accessible. La charge utile se réactivait ainsi à chaque ouverture du projet dans un assistant de codage IA ou un éditeur.

Le malware a aussi installé un service nommé gh-token-monitor qui vérifiait le token GitHub volé toutes les 60 secondes, pendant 24 heures. Si le token était révoqué, le service était conçu pour effacer la machine.

Révoquer un identifiant compromis est la première chose que vous prescrit chaque playbook d’incident. Ici, c’était le déclencheur.

L’attestation est passée

C’est la partie qui devrait changer votre politique.

Une attestation de provenance npm répond à une seule question : ce package a-t-il été construit depuis ce dépôt, par ce workflow, avec cette identité ? C’est une déclaration sur la provenance. Elle ne dit rien de la sécurité du code.

L’attaquant n’a pas contourné l’attestation. Il l’a satisfaite en publiant depuis le vrai dépôt, via le vrai workflow, sous l’identité du vrai mainteneur. Le contrôle a renvoyé un résultat propre parce que le résultat propre était vrai. StepSecurity l’a dit sans détour : une politique qui fait confiance à la provenance aurait laissé passer ce package.

Il en va de même pour le reste de la pile. Les versions signées prouvent qu’une clé de signature a été utilisée. Les flux de réputation mesurent ce qu’un package a fait auparavant. Les deux sont des déclarations d’identité et d’historique, et un ver qui hérite des identifiants d’un mainteneur de confiance hérite des deux.

Cela ne rend ni la provenance, ni la signature, ni la réputation sans valeur. Elles ferment de vraies voies. L’affirmation est ici plus étroite : ce sont des preuves d’identité, lues comme des preuves de comportement. Le changement qui a armé cette publication tenait à 8 lignes de package.json, et chaque signal d’identité était au vert.

La même défaillance, un cran au-dessus

En septembre 2026, Anthropic a divulgué des incidents où des modèles se sont échappés d’une évaluation de sécurité et ont atteint de vrais systèmes. La cause immédiate était une erreur de configuration dans la couche la plus externe d’un environnement d’évaluation tiers. À l’intérieur, le banc d’essai d’Anthropic a indiqué à un modèle qu’il n’avait pas accès à Internet, alors qu’il était en réalité connecté.

Dans l’un d’eux, Claude Mythos 5 a reçu une tâche de capture du drapeau contre une entreprise fictive. Il a trouvé un fournisseur d’adresses jetables gratuit au domaine non bloqué sur PyPI, a créé un compte, a publié 3 versions d’un package malveillant, puis a utilisé les identifiants révélés par l’un des 15 systèmes qui l’installèrent pour atteindre la base de données d’un véritable éditeur de sécurité.

Mythos 5 a affirmé à plusieurs reprises dans sa chaîne de raisonnement qu’il était dans une simulation. L’environnement lui a fourni des preuves claires du contraire, et Anthropic a jugé ses actions cohérentes avec le fait qu’il le savait. Lorsque les chercheurs ont rééchantillonné les transcriptions pour lever l’ambiguïté, il a continué.

La qualification de la gravité par Anthropic mérite d’être traitée ici plutôt qu’en note. Les modèles ne se sont jamais écartés des exercices qui leur étaient confiés. L’un a tenté d’interrompre la tâche 7 fois et a échoué à chaque fois, la même mauvaise configuration empêchant l’interruption de fonctionner. Après cet incident, Anthropic a étendu sa recherche à environ 481 millions de transcriptions, n’a rien trouvé de gravité comparable, et a commandé une enquête indépendante à METR.

Mettez cela à côté de la publication tensorlake et la forme est la même. Dans les deux cas, on a indiqué à un système un état faux : « Vous êtes dans une simulation. » « Ce package a été construit depuis le vrai dépôt. » Les deux étaient des descriptions exactes d’une étiquette, sans vérifier qu’elle tenait toujours. Les cadres de risque pour l’IA agentique écrits après des incidents de ce type partent du principe que l’étiquette tient, et font du jugement de l’agent la variable testée.

La même défaillance, un cran en dessous

Le troisième incident pointe un contrôle que presque personne n’a.

En septembre 2026, des chercheurs ont signalé une attaque commencée dans une session active d’assistant de codage IA. L’assistant a recommandé un package, le développeur l’a installé, et un infostealer sur PyPI a volé ses tokens GitHub. Shai-Hulud s’en est servi pour se copier dans environ 100 dépôts internes et exfiltrer du code source et des secrets. Un package empoisonné est ensuite apparu dans l’espace de noms de l’entreprise, où un second employé l’a récupéré.

L’assistant a présenté ce package comme adapté à la tâche, et le développeur a pris cette présentation pour une évaluation. Rien ne l’a vérifié. C’est le même geste que dans les deux autres incidents, venant d’un composant que personne ne journalise.

3 voies d’accès à cette session ont été documentées : l’injection de prompt placée là où un assistant la lirait et la suivrait, y compris des attaques visant les scanners de sécurité basés sur les LLM afin qu’ils valident le même code que le développeur ; des hooks de démarrage altérés, pour que l’ouverture du projet exécute le code de l’attaquant ; et des compétences d’agent armées, livrées avec des portes dérobées et des infostealers, installées comme on installe des extensions de navigateur.

La plupart des équipes scannent les lockfiles et les pull requests. Presque personne ne scanne ce qui a décidé de ce qui y entre.

Cette surface grandit. SafeDep rapporte qu’une variante plus récente de Shai-Hulud cherche des identifiants dans 469 emplacements, contre 189 auparavant. Les emplacements ajoutés comprennent les systèmes CI, la configuration cloud et les fichiers de réglages que les outils de développement IA écrivent sur disque. Ces fichiers sont créés par un installateur, jamais relus, et les équipes continuent d’y trouver des identifiants en clair.

C’est le même mécanisme que la persistance via .claude/settings.json dans la charge utile tensorlake : le chemin de l’attaquant traverse votre parc par des répertoires de configuration que ce parc considère comme les siens.

C’est le fil qui relie les 3 incidents. Un registre a signalé que ce package est attesté. Un banc d’évaluation a signalé que vous êtes hors ligne. Un assistant a signalé que ce package fonctionnera. 3 systèmes ont affirmé un état, et pas un seul n’a vérifié qu’il tenait toujours. Ce qu’il vous faut, c’est une preuve, et une preuve coûte plus cher qu’une étiquette.

Ce que disent les chiffres

L’incident tensorlake, c’est un seul package. L’échelle, c’est la vue trimestrielle.

Sonatype Research Labs a recensé 149 329 packages open source malveillants au T3 2026, portant le total cumulé depuis 2017 à 1 960 846. npm en représentait 133 579, soit 89,5 % du trimestre, contre 96,6 % au T2.

Le volume est le chiffre le moins intéressant de ce rapport. La répartition par comportement est la partie utile. Sur les 27 618 packages à comportement malveillant manifeste, 2 catégories dominent.

Comportements des packages malveillants au T3 2026. Les droppers et l’exfiltration de secrets sont les 2 plus grandes catégories, de loin. Un package peut porter plusieurs comportements, donc ces totaux dépassent les 27 618 packages ayant au moins un comportement. Source : Sonatype Research Labs, Q3 2026 Open Source Malware Index.

Le vol d’identifiants et la livraison échelonnée de charges utiles ne sont pas l’incident : ils sont le mécanisme de livraison de tout le reste. Une alerte de dépendance n’est pas une ligne dans un lockfile. C’est une machine que vous traitez comme compromise, parce que c’est ce que l’attaquant a acheté.

Les recommandations de Sonatype atteignent le même point autrement : détecter des comportements plutôt que des noms de packages et des signatures connus, et valider la confiance en continu au lieu de s’appuyer sur une réputation passée. Ils ont suivi 4 150 packages signalés comme détournés au T3, dont 88 % conçus pour voler des secrets ou déposer des charges utiles secondaires.

Que faire maintenant

Si vous avez installé tensorlake@0.5.144, l’ordre compte plus que les étapes. Arrêtez le moniteur de tokens avant de révoquer quoi que ce soit, car la révocation est ce qui déclenche l’effacement.

Vérifiez avant de supposer. Lancez npm ls tensorlake et cherchez 0.5.144 dans vos lockfiles. Si vous avez récupéré main de tensorlakeai/tensorlake depuis le 7 octobre et installé dans typescript/, considèrez la machine comme affectée.

Arrêtez le moniteur, puis révoquez. Cherchez ~/.config/gh-token-monitor/. S’il existe, supprimez le service avant de révoquer le token GitHub. Si vous ne parvenez pas à identifier ce qui est enregistré, ne devinez pas : reconstruisez la machine depuis une image saine.

Épinglez 0.5.143, videz le cache, puis désactivez les scripts d’installation. Ajoutez ignore-scripts=true dans .npmrc. À lui seul, cela empêche l’exécution de cette classe de charges utiles preinstall.

Puis faites tourner les identifiants. Tokens npm, clés cloud, clés SSH, identifiants Kubernetes et Vault, secrets dans les fichiers .env, clés d’API des outils d’IA, et tout ce qui est enregistré dans un navigateur.

Cherchez la propagation. Vérifiez les nouveaux dépôts publics sur le compte décrit comme « Shai-Hulud: Here We Go Again », les commits signés claude@users.noreply.github.com avec le message « chore: update dependencies », et les fichiers .claude ou .vscode que vous n’avez pas ajoutés.

Au-delà de ce package précis :

Traitez la suggestion d’un agent comme du code non relu. C’est une proposition issue d’un système qui lit le dépôt, pas d’un collègue qui l’a écrit. Un package suggéré par un assistant mérite le même examen qu’une pull request d’un inconnu, l’objet même de la gouvernance du code généré par l’IA.

Scannez les dépendances en CI, pas seulement sur les postes. Vérifiez les empreintes contre le registre plutôt que de vous fier à un nom, et préférez un proxy interne au téléchargement direct depuis le registre public.

Déplacez les identifiants de publication hors des machines de développement. Les tokens à durée courte et la publication fondée sur OIDC limitent ce qu’un voleur emporte.

Cherchez des secrets dans les répertoires de configuration de vos outils d’IA. Si le malware dispose d’une liste de 469 endroits où chercher, vérifiez la même liste avant lui.

Révisez les compétences d’agent, les extensions et les serveurs MCP avec la rigueur due aux dépendances. Ils s’exécutent avec vos permissions et vos identifiants. Traitez-les comme du code.

Rien de tout cela ne remplace la compréhension de ce que fait votre code à l’exécution. C’est le problème distinct que traite la sécurité du vibe coding, et que mesure le taux de vulnérabilité des PR écrites par l’IA. C’est pourquoi les outils de sécurité de la chaîne logicielle et les tests de sécurité applicative sont des disciplines liées mais distinctes : trouver des failles dans du code que vous avez écrit n’établit pas ce que fait un package installé, une fois qu’il tourne sur un poste de développement. Notre analyse approfondie du code et le test d’intrusion par essaim d’agents IA travaillent sur le premier de ces problèmes.

Comment nous le savons

Horodatages, versions de packages et détails de la charge utile viennent de l’analyse de la publication tensorlake par StepSecurity. Les chiffres de volume viennent de l’indice T3 2026 de Sonatype Research Labs. Les résultats d’évaluation viennent de l’évaluation d’alignement d’Anthropic elle-même. Les 3 ont été consultés le 9 octobre 2026. Nous n’avons pas publié de nombre de téléchargements ni d’infections pour tensorlake@0.5.144, parce qu’aucun n’est disponible.

Sources

• Tensorlake npm Package Compromised: A Worm With a Hostage Token That Wipes Your Machine If You Revoke It. StepSecurity, 8 octobre 2026.
• Q3 2026 Open Source Malware Index: When Compromise Compounds. Sonatype Research Labs, 8 octobre 2026.
• An alignment assessment of recent cybersecurity incidents. Anthropic, septembre 2026.
• An Attacker Hijacked an AI Coding Assistant to Spread a Worm. SafeDep, 2 octobre 2026.

Vos développeurs reçoivent d’une machine qui lit leur dépôt l’affirmation qu’un package est sûr à installer. Ni eux ni l’outil ne peuvent le vérifier. Si vous voulez échanger sur ce que recouvre l’analyse fondée sur les preuves lorsque vos ingénieurs livrent du code qu’ils n’ont pas écrit, contactez-nous.