Guides pratiques pour vous protéger — vous, votre famille et votre entreprise — contre les arnaques liées à l'IA, les deepfakes et les nouvelles menaces cyber.
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 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.
try/except défensifs autour d'opérations triviales, et un usage de l'API GitHub à la fois assuré et légèrement maladroit.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.
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..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.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.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.


