🧩 Une librairie npm qui n’en est pas une
Il y a des jours où l’on regrette presque d’aimer l’open source.
Les chercheurs en cybersécurité viennent de débusquer un nouveau paquet npm malveillant : nodejs-smtp.
Derrière ce nom à l’apparence légitime se cache en réalité une copie trompeuse de la librairie bien connue nodemailer, indispensable pour envoyer des emails dans les projets Node.js.
La manœuvre est simple et redoutablement efficace :
- MĂŞme tagline que le projet officiel.
- Page npm mimant fidèlement l’original.
- README copié-collé pour inspirer confiance.
Résultat : plus de 347 téléchargements avant que l’arnaque ne soit repérée. 347 développeurs qui pensaient installer un outil fiable… et qui ont importé du code toxique.
🎯 La cible : vos wallets crypto
Mais la finalité ne s’arrête pas à un petit troll.
Le package embarquait des scripts furtifs conçus pour injecter du code malveillant dans des applications desktop Windows.
Objectif : voler les données sensibles des portefeuilles de cryptomonnaies.
Deux victimes privilégiées :
- Atomic Wallet – régulièrement ciblé par des campagnes de piratage.
- Exodus Wallet – populaire pour sa simplicité et donc attractif pour les cybercriminels.
Une fois installé, nodejs-smtp tentait d’intercepter ou d’altérer certains processus internes des apps, ouvrant la porte au pillage des clés privées et des fonds.
🕵️ Décryptage technique : comment ça marche ?
En fouillant le code de nodejs-smtp, les analystes ont trouvé plusieurs techniques intéressantes (ou terrifiantes, selon le point de vue) :
- Scripts d’installation détournés
Lors duÂnpm install, un script postinstall dĂ©clenchait un tĂ©lĂ©chargement depuis un serveur tiers. Un grand classique pour ramener du code externe non vĂ©rifiĂ©."scripts": { "postinstall": "node install.js" }Derrière,Âinstall.js rĂ©cupĂ©rait discrètement un binaire et l’injectait dans le système de l’utilisateur. - Injection dans Electron / apps desktop
Le malware scannait les répertoires connus (AppData/Roaming) pour y chercher les installations d’Atomic ou Exodus.
Dès qu’il en trouvait, il modifiait les fichiers de configuration ou insérait du code JavaScript dans les modules Electron. - Exfiltration silencieuse
Les données (mots de passe, seeds, clés privées) étaient ensuite chiffrées basiquement et envoyées vers un serveur command & control via HTTPS, rendant le trafic difficile à distinguer d’une communication normale.
Bref : une supply chain attack taillée sur mesure pour siphonner vos cryptos.
🛠️ La supply chain en ligne de mire
Ce n’est pas un cas isolé. L’écosystème npm est devenu une véritable jungle :
- En 2022, un paquet piĂ©gĂ©Â
ua-parser-js avait infectĂ© des milliers de projets. - En 2023,Â
colors etÂfaker.js avaient provoquĂ© la panique en intĂ©grant volontairement du code perturbateur. - Aujourd’hui, c’estÂ
nodejs-smtp qui tente sa chance.
Pourquoi ça marche ? Parce que la supply chain logicielle repose sur la confiance aveugle. On installe des dépendances comme on achète du pain : vite, sans vérifier l’étiquette.
Mais dans l’open source, le boulanger peut être un cybercriminel en hoodie.
🔍 Comment éviter de tomber dans le piège ?
Quelques règles d’hygiène simples :
- âś…Â VĂ©rifier les noms exacts :Â
nodemailer ≠Ânodejs-smtp. - âś…Â Surveiller la popularitĂ©Â : un projet critique avec 300 tĂ©lĂ©chargements, ça sent le sapin.
- ✅ Checker les mainteneurs : si le compte est nouveau, méfiance.
- âś…Â Analyser le code source (au moins leÂ
package.json et les scripts d’install). - ✅ Mettre en place des scanners de dépendances (npm audit, Snyk, Dependabot).
- âś…Â Limiter la prolifĂ©ration des dĂ©pendances : chaqueÂ
npm install est une porte d’entrée potentielle.
🧠Leçon à retenir
L’affaire nodejs-smtp n’est pas qu’une anecdote de plus.
Elle nous rappelle une vérité inconfortable : les développeurs sont devenus des gardiens de la supply chain numérique.
Chaque dépendance installée est une boîte noire qui peut contenir aussi bien du code utile que du poison. Les attaquants l’ont compris et multiplient les paquets clonés ou typosquattés.
Alors oui, vérifier son package.json n’est pas aussi sexy que coder une nouvelle feature. Mais mieux vaut perdre 5 minutes à lire un README que perdre tous ses bitcoins à cause d’une dépendance pourrie.
💬 Et toi, tu vérifies toujours tes paquets npm avant d’installer, ou tu fais confiance les yeux fermés ?
