Une IA a écrit un malware visant Claude. Il a laissé fuiter ses propres clés.

Une IA a écrit un voleur ciblant Claude. Puis elle s'est fait prendre la main dans le sac.

Le 27 mai 2026, les chercheurs d'OX Security ont rendu publique l'existence d'un paquet npm malveillant — mouse5212-super-formatter — conçu pour une seule mission : exfiltrer en silence tous les fichiers présents dans /mnt/user-data, le dossier sandbox que l'assistant Claude d'Anthropic utilise comme espace de travail (les fichiers déposés par les utilisateurs et les sorties générées par le modèle s'y croisent en permanence). Le paquet a été téléchargé 676 fois avant que npm ne le retire. Et, selon les chercheurs, il a très probablement été écrit par un LLM — un grand modèle de langage, la même famille d'IA que ChatGPT, Claude ou Copilot.

L'intéressant dans cette affaire n'est pas le vol. C'est la maladresse. Le malware embarquait, codée en dur dans son source, une clé d'accès GitHub appartenant à l'attaquant lui-même, en clair, prévue comme solution de repli au cas où l'environnement de la victime n'en fournirait pas. Cette clé a permis à OX Security d'entrer directement dans le dépôt GitHub privé de l'attaquant, de lire les fichiers exfiltrés et de reconstituer toute la campagne. L'IA a aidé l'attaquant à livrer plus vite. Elle lui a aussi fait oublier les règles élémentaires de l'authentification.

Le déroulé

Le paquet se présentait comme un utilitaire « archive deployment sync », formulation suffisamment générique et plausible pour ressembler à ce qu'un LLM produit lorsqu'on lui demande d'inventer de la documentation. D'après l'analyse technique d'OX Security, relayée notamment par The Register et The Hacker News, le comportement malveillant ne se déclenchait pas à l'exécution du code, mais dès l'installation.

Le mécanisme tient en deux mots : postinstall hook. Les paquets npm peuvent embarquer un script postinstall, lancé automatiquement par le gestionnaire de paquets dès qu'un développeur tape npm install, avant même qu'une seule ligne du paquet n'ait été importée par l'application. L'attaquant y avait placé sa charge utile. À l'installation, le script cherchait d'abord dans l'environnement de la victime un jeton d'accès GitHub (la variable GITHUB_TOKEN que d'innombrables workflows de développement et chaînes CI/CD positionnent). À défaut, il basculait sur la clé codée en dur — celle de l'attaquant. Il créait alors un dépôt GitHub privé sous ce jeton, capturait quelques informations réseau de base, puis poussait récursivement tous les fichiers de /mnt/user-data vers ce dépôt. Or ce dossier est précisément l'espace de travail où l'assistant Claude reçoit les fichiers transmis par l'utilisateur, exécute des scripts dans son bac à sable et écrit ses artefacts générés. Jeux de données, code source, fichiers .env, identifiants collés dans une session sandbox : tout y passait.

• Le paquet est resté en ligne suffisamment longtemps pour cumuler 676 téléchargements avant son retrait. Chaque installation représente une exfiltration potentielle, pas une simple consultation.
• Le malware s'authentifiait silencieusement auprès de GitHub, sans aucune interaction utilisateur, car les scripts postinstall s'exécutent avec les droits du développeur ayant lancé l'installation — héritant de toutes les permissions déjà ouvertes dans ce shell.
• La clé de repli codée en dur disposait du périmètre repo sur un dépôt privé contrôlé par l'attaquant. C'est précisément par cette porte qu'OX Security a pu énumérer le contenu volé et identifier d'autres victimes.
• Le code lui-même porte les signatures typiques d'une écriture par LLM : docstrings exagérément verbeuses, noms de variables sortis d'un manuel, blocs try/except défensifs autour d'opérations triviales, et un usage de l'API GitHub à la fois assuré et légèrement maladroit.

Ce que cet incident révèle

L'économie de l'opération est ce qui transforme l'anecdote en signal. Jusqu'à l'an dernier, livrer un voleur fonctionnel exploitant un script postinstall npm exigeait au minimum une bonne maîtrise du cycle de vie de Node, de l'API REST de GitHub, des flux OAuth et une discipline opérationnelle élémentaire — celle qui consiste à ne pas laisser ses propres clés dans le binaire. La barrière n'était pas l'effort, mais la connaissance. Aujourd'hui, un LLM comble cet écart en une après-midi. Reste le jugement comme dernière barrière — et le modèle qui a écrit ce code n'a pas détecté l'erreur opérationnelle avant la mise en ligne.

Pour vos équipes, la conséquence est concrète. Le volume de paquets malveillants assistés par IA qui inondent les registres open source ne va cesser de croître, et le prochain lot ne laissera plus filtrer ses propres identifiants. npm, PyPI ou le hub de modèles Hugging Face sont devenus la surface où le coût marginal d'une nouvelle attaque tend vers zéro. Toute machine de développement qui lance un npm install sur un paquet inconnu — et tout assistant IA de programmation qui exécute des commandes d'installation dans un bac à sable partagé entre utilisateurs — se trouve dans la zone d'impact. Le signal de fond est plus large : on assiste à la première génération de LLM comme auteur de logiciels malveillants en production. Maladroits aujourd'hui, plus soignés d'ici un trimestre.

Les bons réflexes

1. Désactivez par défaut l'exécution des scripts d'installation npm, en CI comme sur les postes de développement. Ajoutez ignore-scripts=true dans le fichier .npmrc des serveurs de build et utilisez npm install --ignore-scripts en local pour toute dépendance inconnue. Les hooks postinstall constituaient ici l'intégralité de la surface d'attaque — les couper neutralise toute la classe d'attaques, pas seulement ce paquet.
2. Traitez les dossiers sandbox des assistants IA comme des cibles d'exfiltration. Si vos ingénieurs utilisent Claude, ChatGPT, Codex ou tout autre assistant de code hébergé dans le cloud, partez du principe qu'un code hostile s'exécutant dans le même bac à sable peut lire tout ce qui y est déposé. Ne confiez jamais à l'assistant vos fichiers .env ou vos identifiants de production. Utilisez des secrets à portée restreinte et à durée de vie courte pour tout ce que l'assistant manipule.
3. Inventoriez les jetons GitHub à longue durée de vie encore présents dans vos variables d'environnement. Le voleur a fonctionné parce que GITHUB_TOKEN est partout : runners CI, shells de développement, configurations d'IDE, images Docker à moitié oubliées. Procédez à un balayage ponctuel : quelles machines et quels pipelines hébergent aujourd'hui un véritable jeton longue durée ? Remplacez chacun par un identifiant OIDC éphémère (la fédération OpenID Connect que GitHub propose nativement) ou par un PAT à granularité fine et à usage unique.

À retenir

L'histoire de mouse5212-super-formatter prête à sourire — un attaquant pris à son propre piège par la négligence de son IA — mais la chute, elle, change d'échelle. Le seuil de production d'un code malveillant fonctionnel a chuté à celui de l'écriture d'un utilitaire npm bâclé. La prochaine vague d'attaquants ne laissera pas filtrer ses clés. Considérez le registre public, et le bac à sable de votre assistant, pour ce qu'ils sont silencieusement devenus : un environnement hostile.