Je viens de passer ma journée entière dans Claude Code : je l'ai laissé lire mon dépôt, exécuter des commandes, modifier mes fichiers et pousser sur GitHub. Alors quand j'ai vu passer une étude montrant qu'on peut piéger ce même outil pour lui faire installer un malware, ça m'a fait tout drôle.
Des chercheurs de l'équipe 0din de Mozilla ont démontré qu'un agent IA de code comme Claude Code peut être manipulé pour exécuter un logiciel malveillant — simplement en lui demandant d'initialiser un projet depuis un dépôt GitHub d'apparence parfaitement normale. Pas de faille système, pas de pièce jointe vérolée : l'agent se fait avoir par sa propre serviabilité. Voici ce que ça révèle, et comment j'adapte ma façon de bosser sans pour autant lâcher l'outil.
Ce que les chercheurs ont montré
Le scénario est d'une simplicité déstabilisante. Un développeur demande à son agent IA d'initialiser ou de configurer un projet à partir d'un dépôt GitHub. Le dépôt a l'air propre. L'agent, pour faire son travail, lance un script de configuration — une opération banale que personne ne questionne.
Le piège est dans ce que ce script va chercher. Au lieu de télécharger sa charge depuis une URL malveillante (qui pourrait être scannée et bloquée), il va lire une information cachée dans un endroit inattendu : les enregistrements DNS d'un domaine d'apparence anodine. Le DNS ne transporte pas le malware lui-même, mais une instruction encodée — un canal discret qui sert à récupérer ou reconstruire la charge utile, et qui échappe aux scans d'URL. Ce détour ne déclenche aucune alerte, parce qu'il ressemble à une opération technique légitime. Au bout de la chaîne, le code ainsi récupéré ouvre un accès distant à la machine du développeur (source : Tom's Hardware).
À partir de là, l'attaquant a la main sur le compte du développeur : ses secrets, ses clés d'API, son code, ses sessions de navigateur, ses mots de passe. Et il peut installer d'autres logiciels pour garder un accès permanent. Les chercheurs précisent que Claude est visé parce qu'il est l'outil par défaut pour programmer, mais que cette famille d'attaques concerne la plupart des agents capables d'exécuter des actions de façon autonome, quel que soit leur fournisseur.
Important pour ne pas paniquer : il s'agit d'une démonstration de chercheurs, pas d'une vague d'attaques en cours dans la nature. Mais une démonstration qui marche, c'est exactement ce qui précède les attaques réelles.
Pourquoi ça fonctionne (et pourquoi c'est malin)
La faille n'est pas un bug classique. Elle est architecturale, et elle tient en une phrase : un agent IA ne sait pas distinguer de façon fiable une donnée qu'il lit d'une instruction qu'il doit exécuter. Tout, pour lui, c'est du texte à interpréter.
Du coup, du contenu soigneusement formaté — dans un fichier de config, un commentaire, une réponse d'outil — peut être lu par l'agent comme un ordre. Et comme l'agent agit de façon autonome, avec tes identifiants et tes permissions, l'ordre malveillant s'exécute avec tous tes droits. L'agent n'a même pas besoin d'élever ses privilèges : il agit déjà avec ceux que tu lui as confiés. Le génie de l'attaque, c'est qu'elle n'utilise que des opérations d'apparence normale : initialiser un projet, lancer un script, récupérer une config. Rien qui fasse sonner une alarme. Les antivirus traditionnels sont d'ailleurs moins efficaces face à ce type d'attaque : l'élément malveillant arrive sous forme de texte interprété par l'agent, pas d'un exécutable téléchargé directement.
C'est ce que la communauté sécurité appelle le « prompt injection » (ou détournement d'objectif de l'agent), et il figure en tête du Top 10 OWASP consacré aux applications à base d'agents pour 2026. Ce n'est pas une bizarrerie de labo : c'est le talon d'Achille de toute une génération d'outils — les agents IA de code, ou AI coding agents, comme Claude Code, Cursor ou Codex.
Ce n'est pas un cas isolé
L'étude de Mozilla s'inscrit dans une série qui s'accumule depuis le début de l'année, et c'est ça qui doit nous alerter.
En juin 2026, des chercheurs de Tenet ont dévoilé une attaque baptisée « agentjacking » : en injectant un faux rapport d'erreur dans un service de monitoring (via une intégration MCP), ils ont fait exécuter des commandes à Claude Code, Cursor et Codex, avec un taux de réussite d'environ 85 % lors de leurs tests (source : Cybersecurity News). Fin mars 2026, deux versions malveillantes du paquet npm axios — l'une des bibliothèques JavaScript les plus téléchargées au monde, compromises via un compte mainteneur piraté — ont diffusé un cheval de Troie d'accès distant avant d'être retirées. Le danger est décuplé par le fait que les agents IA lancent npm install tout seuls, sans validation humaine : ils peuvent donc tirer une version vérolée sans que personne ne s'en aperçoive.
À cela s'ajoutent les serveurs MCP piégés. Un serveur MCP, c'est une extension qui permet à un agent d'interagir avec des outils externes — GitHub, une base de données, un navigateur. Très pratique, mais c'est aussi une surface d'attaque : un serveur malveillant ou compromis peut glisser des instructions cachées dans ce que l'agent lit.
Le fil rouge est toujours le même : l'agent fait confiance à ce qu'il lit, agit vite, et tout seul. Trois qualités qui font sa puissance, et trois portes d'entrée.
Ce que ça change pour moi — et pour toi si tu codes avec une IA
Je vais être direct, parce que ça me concerne personnellement. Aujourd'hui même, j'ai donné à Claude Code accès à mon dépôt, je l'ai laissé exécuter des commandes PowerShell et pousser du code. Le confort que j'adore — déléguer, le laisser faire tourner les choses — c'est précisément la surface d'attaque décrite par ces chercheurs.
Je ne vais pas arrêter de l'utiliser ; il m'a fait gagner un temps fou aujourd'hui. Mais cette étude change mes habitudes, et voici concrètement comment. Je ne laisse pas l'agent en mode « j'approuve tout automatiquement » : je lis ce qu'il s'apprête à exécuter avant de valider, surtout les commandes shell et les installations de paquets — c'est exactement ce que j'ai fait toute la journée en relisant ses diffs avant de les appliquer. Je me méfie comme de la peste de l'idée d'initialiser ou de configurer un projet inconnu en lui lâchant la bride. Je garde mes secrets et mes clés d'API hors de portée immédiate d'un agent — variables d'environnement injectées seulement à l'exécution, permissions minimales, token GitHub limité au dépôt courant plutôt qu'un accès large — parce qu'une instruction injectée ira les chercher là où elles traînent. Et je traite désormais tout ce que l'agent lit depuis l'extérieur — un dépôt, un log d'erreur, un paquet, une page web — comme potentiellement hostile.
Rien de tout ça n'est paranoïaque. C'est juste le réflexe qu'on a déjà avec le code des autres, étendu à un assistant qui agit à notre place.
Les réflexes que j'applique désormais
- Lire chaque commande shell avant de la valider.
- Vérifier les scripts d'installation (
install.sh,setup.ps1,postinstall…). - Limiter les permissions GitHub et les clés d'API au strict nécessaire.
- Tester un dépôt inconnu dans un environnement isolé.
- Se méfier des instructions cachées dans les logs, les README ou les commentaires.
- Désactiver l'approbation automatique quand c'est possible.
À retenir
- Des chercheurs de Mozilla (équipe 0din) ont piégé Claude Code pour lui faire installer un malware via un dépôt GitHub d'apparence propre.
- Le mécanisme exploite une faiblesse de fond : un agent IA ne distingue pas une donnée d'une instruction, et il agit avec tes identifiants.
- C'est une démonstration de recherche, mais elle s'ajoute à une série (agentjacking, axios npm, serveurs MCP piégés).
- L'OWASP classe ce type d'attaque (« prompt injection ») comme risque numéro un des agents IA en 2026.
- La parade n'est pas d'arrêter : c'est de relire avant d'approuver, scoper les permissions, et traiter tout contenu externe comme suspect.
FAQ
Claude Code est-il dangereux à utiliser ?
Non, pas en soi. Le risque vient de l'usage : laisser un agent exécuter des actions sans relecture, sur du contenu ou des dépôts non vérifiés. Utilisé avec des garde-fous adaptés — validation des commandes, permissions limitées —, il reste un outil sûr au quotidien.
Comment un agent IA peut-il installer un malware ?
En interprétant comme une instruction du contenu malveillant qu'il lit (dans un dépôt, un log, un paquet). Comme il agit avec tes permissions, l'instruction cachée s'exécute avec tes droits, sans déclencher d'alerte antivirus.
Est-ce que ça ne touche que Claude Code ?
Non. Claude est visé parce qu'il est le plus utilisé pour coder, mais Cursor, Codex, Copilot et les autres partagent la même faiblesse architecturale. C'est un problème de catégorie, pas d'un seul produit.
Comment me protéger en tant que développeur ?
Ne valide pas les actions de l'agent à l'aveugle, relis les commandes shell et les installations avant approbation, n'initialise pas de projet inconnu sans méfiance, limite les permissions et l'accès aux secrets, et isole l'environnement pour le code non vérifié.
Faut-il arrêter d'utiliser les agents IA pour coder ?
Non. Le bon réflexe n'est pas l'abandon mais l'adaptation : les mêmes précautions qu'avec le code d'un inconnu, appliquées à un assistant qui agit à ta place.
Mon verdict
Ce qui me frappe dans cette histoire, c'est qu'il n'y a pas de « faille » à patcher au sens classique : le problème, c'est la nature même d'un agent qui lit du texte et agit dessus. Tant qu'on ne saura pas apprendre à ces outils à se méfier de ce qu'ils lisent, la vigilance restera de notre côté. Je continue d'utiliser Claude Code — il m'est devenu indispensable — mais avec une règle que je n'avais pas vraiment intégrée avant aujourd'hui : un agent qui agit pour moi mérite la même prudence que du code écrit par un inconnu. La confiance aveugle, c'est exactement ce que l'attaque attend.
→ Voir aussi : GPT-5.6 et Mythos : Washington filtre l'accès à l'IA de pointe