Un simple npm install suffisait à se faire voler ses clés : le paquet jscrambler compromis

La version 8.14.0 de jscrambler, publiée le 11 juillet sur npm, exécutait un voleur de données dès l'installation. Une attaque courte, vite repérée, mais qui visait précisément les machines les plus sensibles : celles des développeurs. On vous explique ce qui s'est passé, et surtout quoi faire.

Samedi 11 juillet, une nouvelle version du paquet npm jscrambler, un outil de protection et d'obfuscation de code JavaScript utilisé en build et en CI, apparaît sur le registre : la 8.14.0. En apparence, une mise à jour comme une autre. En réalité, l'installer déclenchait immédiatement l'exécution d'un malware.

La société Socket, spécialisée dans la sécurité de la chaîne d'approvisionnement logicielle, a repéré la version malveillante six minutes après sa publication. Un délai record, mais qui laisse une fenêtre : toute machine ou tout pipeline de CI ayant récupéré le paquet dans l'intervalle doit être considéré comme compromis.

Comment fonctionnait le piège

Le mécanisme est d'une efficacité redoutable, et il repose sur une fonctionnalité tout à fait légitime de npm : les scripts d'installation. La version piégée ajoutait deux fichiers dans le dossier dist du paquet. Le premier, setup.js, est un petit chargeur déclenché par un hook preinstall, c'est-à-dire exécuté automatiquement avant même la fin de l'installation. Le second, baptisé intro.js, n'a de JavaScript que l'extension : c'est en réalité un conteneur d'environ 7,8 Mo embarquant trois binaires natifs compressés, un pour Linux, un pour Windows, un pour macOS.

À l'installation, le chargeur identifie votre système, extrait le binaire correspondant, l'écrit sous un nom aléatoire dans le dossier temporaire, le rend exécutable et le lance en arrière-plan, sortie masquée. L'utilisateur ne voit rien.

Détail révélateur : ces fichiers n'existent nulle part dans le code source public du projet. Les chercheurs de StepSecurity et de SafeDep, qui ont analysé la version, n'ont trouvé ni commit, ni tag, ni pull request correspondant à la 8.14.0 sur le dépôt GitHub, dont la dernière version officielle reste la 8.13.0. La version a donc été poussée directement sur npm depuis un compte mainteneur légitime, en contournant le processus normal de publication. Compte npm piraté ou pipeline de build compromis ? À l'heure où nous écrivons, la question n'est pas tranchée.

Ce que le malware cherchait

Le binaire est un infostealer écrit en Rust, compilé pour les trois plateformes, qui ratisse la machine à la recherche de secrets avant de les exfiltrer en TLS vers un serveur de collecte. Sa liste de courses est taillée pour les développeurs : identifiants cloud AWS, Azure et Google Cloud (y compris via les endpoints de métadonnées qu'utilisent les runners de CI), portefeuilles de cryptomonnaies et phrases de récupération (MetaMask, Phantom, Exodus), coffre Bitwarden, mots de passe et cookies des navigateurs, sessions Discord, Slack, Telegram et Steam.

Et un ajout qui signe l'époque : le malware ciblait aussi les fichiers de configuration des outils de développement assistés par IA, dont Claude Desktop, Cursor, Windsurf, VS Code et Zed, là où traînent désormais des clés d'API et des identifiants de serveurs MCP. Les voleurs de données ont bien compris où la valeur s'est déplacée.

Le malware ne se contentait pas de voler. Sur Windows, il installait une tâche planifiée cachée relancée toutes les minutes ; sur macOS, un LaunchAgent rechargé à chaque connexion ; sur Linux, plus inquiétant, il embarquait la capacité de charger un programme eBPF directement dans le noyau depuis la mémoire, un niveau d'ancrage bien plus profond que le simple vol de fichiers. Les analyses ont aussi relevé des communications vers deux adresses IP codées en dur et vers l'infrastructure Tor.

Faut-il paniquer ? Non. Faut-il vérifier ? Oui.

Remettons l'affaire à sa juste place. jscrambler pèse environ 17 000 téléchargements par semaine : on est loin des compromissions géantes de l'écosystème npm ces derniers mois, comme le ver Shai-Hulud ou l'affaire des paquets chalk et debug, qui touchaient des paquets téléchargés des milliards de fois. Et la fenêtre d'exposition a été courte.

Mais pour un malware qui vise les machines de build, le volume n'a jamais été le sujet. Une seule machine de CI compromise, ce sont des clés de déploiement, des tokens npm et du code source qui partent. C'est exactement pour ça que ce genre d'attaque, dite de la chaîne d'approvisionnement, est devenu le vecteur préféré des attaquants : on ne pirate plus mille entreprises, on pirate un paquet que mille entreprises installent.

Concrètement, que faire

Si vous utilisez jscrambler : vérifiez immédiatement si la version 8.14.0 est passée par vos environnements, en local comme en CI (npm ls jscrambler, et un grep sur vos lockfiles). Si oui, considérez la machine compromise : révoquez et regénérez tous les secrets qu'elle pouvait atteindre (clés cloud, tokens npm et Git, clés d'API, y compris celles de vos outils IA), cherchez les mécanismes de persistance décrits plus haut, et dans le doute, réinstallez proprement la machine. La version malveillante a depuis été retirée du registre npm, et l'éditeur a publié de nouvelles versions saines dans la foulée : mettez à jour vers la dernière version disponible.

Pour tout le monde, trois réflexes qui auraient bloqué ou limité cette attaque :

1. Désactivez les scripts d'installation par défaut (npm config set ignore-scripts true). C'est le hook preinstall qui a tout déclenché ici ; la plupart des paquets n'en ont pas besoin, et vous pouvez réactiver au cas par cas.
2. Épinglez vos versions et ne mettez pas à jour à chaud. Un lockfile respecté et un délai de quelques jours avant d'adopter une version fraîchement publiée (certains outils permettent d'imposer un âge minimum de publication) vous auraient tenu hors de la fenêtre des six minutes.
3. Cloisonnez vos CI : des tokens à durée courte, aux permissions minimales, transforment un vol de secrets en incident gérable plutôt qu'en catastrophe.

La chaîne d'approvisionnement logicielle restera un terrain d'attaque privilégié : elle offre un effet de levier maximal pour un effort minimal. Signe que le problème est pris au sérieux, npm a d'ailleurs engagé un durcissement de ses règles de publication : les tokens qui permettent de contourner la double authentification, précisément le genre de mécanisme qui rend possible une publication frauduleuse depuis un compte mainteneur, seront progressivement restreints d'ici début 2027. La bonne nouvelle, c'est que la détection s'améliore (six minutes !) et que les contre-mesures ci-dessus sont à la portée de n'importe quelle équipe. La moins bonne, c'est qu'il faudra désormais compter vos clés d'API d'assistants IA parmi les bijoux de famille à protéger.

Sources : analyses de Socket, StepSecurity et SafeDep, via The Hacker News, 11 juillet 2026.