voteinutile.fr logo

npm : le package jscrambler piégé par un infostealer, près de 1 500 installations avant l’alerte

Quand un outil de sécurité devient le cheval de Troie, l’ironie a un goût amer. Le package npm jscrambler, signé par une société spécialisée dans la protection du code JavaScript côté client, a été publié dans une version vérolée embarquant un infostealer. Avant que quiconque ne tire la sonnette d’alarme, la chose avait déjà été téléchargée près de 1 500 fois.

La société Jscrambler a confirmé qu’un acteur malveillant avait poussé une version frauduleuse de son package. Cible privilégiée : les environnements de développement et les chaînes d’intégration continue qui avalent les dépendances npm sans réfléchir.

Points clés

  • Le package npm jscrambler a été publié dans une version vérolée téléchargée près de 1 500 fois avant détection.
  • L’infostealer, écrit en Rust, vise identifiants cloud, portefeuilles crypto, cookies et sessions Discord, Slack ou Steam.
  • L’attaque provient d’un identifiant de publication npm compromis, contournant la validation du code source.
  • Les binaires malveillants ciblent Windows, macOS et Linux et s’exécutent dès l’installation via un script preinstall.

Une version piégée qui s’exécute toute seule

Le package touché est jscrambler, distribué via npm. La version malveillante se déclenche dès l’installation grâce à un script preinstall, sans le moindre clic supplémentaire de la victime. Le code dépose et lance un binaire natif pour Windows, macOS et Linux. Le service complet, en somme.

Les analyses publiées par Socket décrivent un infostealer écrit en Rust, qui ratisse les secrets des développeurs :

  • des identifiants cloud pour AWS, Azure et Google Cloud ;
  • des portefeuilles crypto et leurs phrases de récupération ;
  • des données de navigateurs, mots de passe et cookies compris ;
  • des sessions d’outils comme Discord, Slack, Telegram et Steam.

Les versions incriminées débutent par la 8.14.0, suivie d’autres variantes publiées sur une courte période. Certaines basculent vers d’autres mécanismes d’exécution, histoire de contourner les protections qui se contentent de désactiver les scripts d’installation. Désactiver preinstall ne suffit donc pas à dormir tranquille.

Un identifiant de publication compromis

Jscrambler pointe la source du mal : un identifiant de publication npm compromis. Les versions frauduleuses ont été injectées directement dans le registre, en court-circuitant le flux habituel de validation du code source. Le maillon faible n’était pas le code, mais la clé qui ouvre la porte.

Socket dit avoir repéré la première version compromise en quelques minutes. Détection éclair, certes, mais insuffisante : les téléchargements ont continué et le compteur a grimpé jusqu’à près de 1 500 installations.

Les équipes ayant installé jscrambler pendant la fenêtre d’exposition doivent considérer comme compromis tout environnement susceptible d’avoir exécuté la version piégée. Traduction : passer au peigne fin les journaux de build, les lockfiles et l’ensemble des secrets accessibles depuis la machine.

Ce qu’il faut vérifier

Premier réflexe pour les environnements npm : traquer la présence de la version compromise dans les dépendances directes ou transitives. Ensuite, inspecter les postes et pipelines pour repérer une exécution de script d’installation suspecte, une connexion vers des serveurs inconnus ou des fichiers temporaires apparus de nulle part.

L’incident reste une attaque de supply chain logicielle classique, mais son terrain de chasse est vaste : un package destiné aux développeurs se retrouve intégré dans des chaînes automatisées. Un infostealer sur une machine de build ne se contente pas du projet visé. Clés cloud, jetons GitHub, secrets CI et accès stockés en local partent avec le reste. Pour un éditeur qui vend de la sécurité applicative, la leçon est cinglante : la meilleure serrure ne vaut rien si l’on égare la clé.

Commentaires