Contexte et découverte

Le 22 septembre 2026, Checkmarx a signalé la présence d’un paquet npm nommé indexed-btree, publié le 18 juin 2026 par l’utilisateur charlessadler25. En moins d’un mois, le module a accumulé plusieurs millions de téléchargements avant d’être retiré du registre. L’enquête a révélé que le groupe d’attaque a perçu environ 230 933,57 € (soit 109 ETH) grâce aux revenus générés par le malware.

Cette campagne coïncide avec la mise à jour npm v12, qui bloque l’exécution automatique des scripts de cycle de vie (preinstall, postinstall). Historiquement, ces hooks constituaient le vecteur principal des attaques de chaîne d’approvisionnement. Leur désactivation a poussé les acteurs malveillants à repenser leur méthode d’injection.

Mécanisme d’injection au runtime

Contrairement aux attaques classiques, indexed-btree n’utilise aucun hook d’installation. Le code malveillant est intégré dans la fonction BTree.prototype.set() du module, qui est invoquée lors de l’utilisation normale de la bibliothèque. Cette fonction charge sharedLoad.min.js, un payload JavaScript obfusqué qui constitue la première étape du malware.

Le chargeur effectue d’abord une empreinte du système hôte (OS, versions Node, variables d’environnement) puis transmet ces informations à un canal Slack et à un bot Telegram préconfigurés. Ensuite, il applique la technique EtherHiding : il interroge un contrat intelligent déployé sur le testnet Sepolia pour récupérer des blobs chiffrés, les déchiffre et les assemble en une charge utile de deuxième étape. Après l’exécution, le code supprime les artefacts et retire le déclencheur de BTree.prototype.set() afin d’effacer les traces.

Le même mode opératoire a été identifié dans d’autres paquets supprimés simultanément (ordered-kv-index, btree-leaderboard, priority-slot-queue, etc.), confirmant une campagne coordonnée.

Analyse des impacts et contre‑mesures

Le déplacement du point d’exécution du moment de l’installation vers le runtime rend les scanners basés uniquement sur les hooks d’installation inefficaces. Les métriques montrent que même avec des millions de téléchargements, le temps d’exposition réel dépend de l’invocation de la méthode set() dans les applications clientes, ce qui rend la détection plus difficile.

Les experts recommandent une approche en couches : combiner l’analyse statique des dépendances avec une surveillance dynamique du comportement des modules au moment de l’exécution. Des solutions de sandboxing ou d’instrumentation du runtime Node.js peuvent identifier les appels réseau inhabituels (vers Slack, Telegram ou un nœud Ethereum) et les accès à des contrats intelligents.

Enfin, la mise à jour npm v12 reste pertinente : elle élimine le vecteur le plus simple, mais ne constitue pas une barrière absolue. Les équipes de sécurité doivent élargir leurs politiques de validation des paquets, intégrer des listes de réputation et appliquer des contrôles d’intégrité au niveau du code source, notamment pour les fonctions publiques exposées par les bibliothèques tierces.