Un attaquant a détourné le paquet npm de Jscrambler avec un identifiant de publication volé et diffusé un infostealer aux développeurs entre le 11 et le 13 juillet 2026. Le logiciel malveillant récoltait jetons cloud, portefeuilles et identifiants d'assistants IA sur toute machine l'ayant installé. Pour les équipes de risque tiers, la leçon est qu'une dépendance de confiance est un fournisseur, et que son canal de diffusion peut devenir la voie de l'attaque.
Un attaquant a pris le contrôle du paquet npm de Jscrambler, une société qui vend des outils de protection du code JavaScript, et s'en est servi pour diffuser un logiciel malveillant aux développeurs qui lui font confiance. Entre le 11 et le 13 juillet 2026, la société de sécurité Socket a découvert cinq versions malveillantes du paquet populaire jscrambler (npm est le principal registre de code JavaScript). Chacune déposait un programme caché qui vole les secrets présents sur la machine où il s'exécute. Toute personne dont le poste ou le système de build a installé une version concernée a pu laisser fuir des jetons cloud, des accès au code source et davantage. Jscrambler a confirmé que les paquets avaient été publiés avec l'un de ses propres identifiants volés. La leçon : un fournisseur auquel vous confiez la protection de votre code peut devenir la voie par laquelle l'attaque entre.
Ce qui s'est passé
Socket a signalé la compromission le 11 juillet 2026 et l'a mise à jour le 13 juillet 2026, et Jscrambler a publié un avis de sécurité confirmant l'incident. Le 11 juillet, un attaquant a publié une version malveillante du paquet jscrambler (8.14.0), suivie de quatre autres (8.16.0, 8.17.0, 8.18.0 et 8.20.0) en quelques heures. Jscrambler indique que l'attaquant a pu publier en utilisant l'un des identifiants de publication npm de la société (la clé qui permet à un mainteneur de diffuser un paquet). Le paquet enregistre environ 15 800 téléchargements par semaine. Les versions malveillantes déposaient un infostealer écrit en Rust (un programme d'arrière-plan qui récolte des secrets) conçu pour Linux, macOS et Windows. Les premières versions l'exécutaient via un hook preinstall, c'est-à-dire automatiquement à l'installation. Les versions ultérieures ont déplacé le code dans les fichiers du paquet pour qu'il s'exécute lors de l'importation, un changement que Socket décrit comme un moyen de contourner les scanners qui n'inspectent que les scripts d'installation. La charge visait les identifiants cloud (Amazon, Google et Microsoft), les portefeuilles de cryptomonnaie, les messageries, les données de navigateur et, notamment, les fichiers de configuration des assistants de codage IA et de leurs outils connectés, qui contiennent souvent des clés d'API. Socket a signalé la première version six minutes après sa publication. Jscrambler a révoqué et renouvelé l'identifiant, déprécié les versions concernées et publié une version saine (8.22.0). Le nombre de machines ayant installé une version malveillante n'est pas confirmé.
Pourquoi cela compte pour le risque tiers
C'est le schéma de la dépendance de confiance, dans une version aiguë. La victime n'était pas un typosquat ni un nom ressemblant qu'un développeur pourrait repérer. C'était le vrai paquet d'un éditeur de sécurité, détourné à la source. Chaque composant open source qu'un build intègre est un fournisseur, et le canal de diffusion de ce fournisseur était le maillon faible. L'exposition ne s'arrête pas à un seul ordinateur portable. Des jetons de build, des clés cloud et des accès aux dépôts volés atteignent les systèmes et les clients en aval de toute chaîne concernée. Le ciblage des configurations d'assistants IA et d'outils connectés est la nouveauté : ces fichiers contiennent de plus en plus d'identifiants actifs, si bien que la chaîne d'approvisionnement des développeurs inclut désormais les secrets logés dans leurs propres outils.
Ce que les équipes devraient en retenir
Traitez votre registre de dépendances comme un parc de fournisseurs, pas comme une étagère en libre-service. Épinglez des versions exactes, examinez les changements avant qu'ils n'entrent dans un build et préférez des versions qui ont mûri plutôt que d'installer automatiquement la dernière étiquette. Ensuite, partez du principe que tout secret ayant transité par un environnement de build est atteignable : renouvelez les identifiants cloud, de dépôt et d'outils IA sur toute machine ayant installé une version concernée, et vérifiez que les fichiers de configuration des assistants IA ne stockent pas de clés durables en clair.
Pour les équipes qui cartographient les fournisseurs logiciels susceptibles de porter ce type de risque, voyez comment fonctionne la surveillance continue des fournisseurs et des dépendances.
FAQ
Le produit de Jscrambler lui-même a-t-il été violé ?
Jscrambler a confirmé que son paquet npm avait été publié sans autorisation à l'aide d'un identifiant de publication volé. La société indique avoir renouvelé l'identifiant et les secrets associés et ajouté des contrôles autour de la publication. L'ampleur d'un accès plus large n'est pas détaillée dans l'avis.
Quelles versions sont concernées, et lesquelles sont sûres ?
Socket répertorie 8.14.0, 8.16.0, 8.17.0, 8.18.0 et 8.20.0 comme malveillantes. La version 8.13.0 (avant le détournement) et la 8.22.0 (le correctif) sont décrites comme saines. Les équipes devraient passer à la 8.22.0 et auditer toute machine ayant installé l'une des versions malveillantes.
Que faire si une équipe a installé une version malveillante ?
Renouvelez tout identifiant accessible depuis le poste ou le système de build concerné, y compris les clés cloud, les jetons de dépôt et les clés d'API stockées dans les fichiers de configuration des assistants IA. Recherchez les versions concernées dans les arbres de dépendances et les journaux d'intégration continue, et considérez les secrets exposés comme compromis plutôt que d'attendre une preuve.
Vous souhaitez appliquer cela à votre écosystème fournisseurs ? Découvrez la plateforme en action et cartographiez vos principaux risques fournisseurs en direct lors d'une présentation.
