Je souhaite vous informer d’une alerte de sécurité majeure qui agite actuellement la communauté des développeurs JavaScript. Il s’agit d’une attaque de la chaîne d’approvisionnement logicielle touchant l’écosystème npm : pas moins de 18 packages très populaires (notamment chalk et debug) ont été compromis via le piratage du compte d’un mainteneur. En conséquence, des versions malveillantes de ces bibliothèques ont été publiées le 8 septembre 2025, intégrant du code conçu pour intercepter des transactions en cryptomonnaies. Ces packages totalisent plus de 2 milliards de téléchargements hebdomadaires, ce qui fait de cet incident l’un des plus graves jamais observés sur npm en termes de portée potentielle.
Rappel du contexte de l’attaque
L’incident a débuté lorsque le compte npm d’un mainteneur (Josh Junon, alias “Qix”) a été compromis par une campagne de phishing ciblée. Le mainteneur a reçu un courriel prétendant provenir du support officiel de npm (support@npmjs.help), l’invitant à mettre à jour ses paramètres d’authentification à deux facteurs (2FA). Malheureusement, en suivant le lien frauduleux vers un faux site imitant npm, il a involontairement divulgué ses identifiants et le code 2FA aux attaquants. Ceux-ci ont pu aussitôt se connecter à son compte npm, publier de nouvelles versions corrompues des packages qu’il gérait, puis ont changé l’adresse e-mail associée au compte pour en exclure le propriétaire légitime.
La compromission concerne au total 18 modules JavaScript largement utilisés, dont des outils aussi répandus que chalk (mise en forme de texte console), debug (journalisation de débogage), ainsi que toute une chaîne de dépendances associées (par exemple ansi-styles, supports-color, has-ansi, strip-ansi, etc.). À partir de 13h16 UTC le 8 septembre, des versions contenant du code malveillant ont été publiées pour chacun de ces packages. Alertée par son système de veille, la société de sécurité Aikido Security a rapidement identifié la menace et contacté le mainteneur via le réseau social Bluesky. Celui-ci a confirmé à 15h15 UTC avoir été victime d’hameçonnage et s’est immédiatement attelé à retirer les versions infectées. Grâce à cette réaction coordonnée, la fenêtre d’exposition est restée brève : en l’espace de quelques heures, les versions compromises ont été retirées du registre npm et remplacées par des versions saines.
Un malware voleur de cryptomonnaies…
Le code injecté par les attaquants au sein de ces packages agit comme un malware côté navigateur sophistiqué. Concrètement, dès qu’une application web charge l’une des bibliothèques compromises, le script malveillant s’exécute sur la machine de l’utilisateur final dans le contexte du navigateur. Il va alors détourner des fonctions clés de la page web et de la chaîne d’exécution JavaScript afin d’espionner et de manipuler les transactions en cryptomonnaies :
- Il surveille l’activité des portefeuilles numériques (par exemple en détectant l’objet
window.ethereumutilisé par MetaMask et d’autres wallets Ethereum) et intercepte les appels aux APIs de portefeuille. - Il s’injecte dans les fonctions réseau telles que
fetchetXMLHttpRequestafin d’examiner silencieusement les données échangées avec les serveurs. Le malware recherche dans les réponses toute séquence ressemblant à une adresse de portefeuille (Ethereum, Bitcoin, Solana, Tron, etc.). - Lorsqu’il repère une transaction ou une adresse de destination, le malware substitue celle-ci par une adresse contrôlée par l’attaquant. Il utilise notamment des adresses « look-alike » (visuellement proches) et des techniques de calcul de distance (distance de Levenshtein) pour remplacer l’adresse légitime par une adresse malveillante similaire, rendant la modification peu apparente.
- Juste avant la signature d’une transaction par l’utilisateur, le code malveillant modifie en temps réel les destinataires et montants dans les données de transaction (par exemple les paramètres des appels Ethereum comme
transferouapprove). Ainsi, même si l’interface du portefeuille ou du site semble afficher les bonnes informations, la transaction signée oriente les fonds vers l’attaquant à l’insu de l’utilisateur. - Le malware prend soin de rester discret : s’il détecte la présence d’un wallet, il évite d’effectuer des changements trop visibles dans l’interface utilisateur, et il continue à tourner en arrière-plan pour intercepter d’autres opérations sans attirer l’attention.
L’objectif de ce code était clairement le vol de cryptomonnaies. En revanche, il est important de noter que le malware ne déployait aucune charge utile supplémentaire en dehors du navigateur : il ne cherchait pas à accéder au système de fichiers, ni à installer un backdoor sur la machine de développement ou du serveur. Cette attaque avait donc un périmètre volontairement restreint aux actifs numériques transitant via les applications web vulnérables.
Impact et portée de l’incident
Bien que cette attaque soit exceptionnelle par l’ampleur potentielle (les librairies compromises sont utilisées sur d’innombrables projets et sites web), son impact effectif semble jusqu’ici limité. La campagne a été stoppée rapidement, ce qui a réduit le nombre d’applications ayant pu embarquer les versions piégées. À l’heure où j’écris ces lignes, aucune perte majeure de cryptomonnaie n’a été rapportée publiquement. En effet, selon les premières analyses, les fonds détournés par les attaquants seraient dérisoires (quelques centimes d’euro tout au plus). Ce paradoxe – une attaque touchant possiblement des milliards de téléchargements, mais n’ayant pratiquement causé aucun dégât financier – s’explique par la combinaison d’une détection rapide et d’un choix de cible relativement spécifique (les transactions crypto) limitant l’impact aux utilisateurs effectuant de telles opérations durant la brève fenêtre de compromission.
Il n’en demeure pas moins que l’incident aurait pu être bien plus grave. En compromettant ainsi la chaîne de distribution de code, des attaquants malveillants auraient pu tout aussi bien insérer un malware beaucoup plus destructeur : vol de jetons d’authentification développeur (tokens npm, GitHub, clés SSH/API) ou installation de portes dérobées dans des systèmes clients, par exemple. La communauté de la cybersécurité souligne que nous avons probablement évité le pire scénario de justesse. Cet événement met donc en lumière la vulnérabilité des infrastructures open source face aux attaques ciblant les mainteneurs. D’ailleurs, cette affaire survient quelques semaines à peine après une autre compromission par phishing d’un package npm très téléchargé (nx fin août 2025), signe que ces attaques de supply chain se multiplient.
Réactions et conseils de sécurité
Suite à cette alerte, les équipes de sécurité (CERT, SOC) du monde entier ainsi que de nombreux développeurs se sont mobilisés pour évaluer leur exposition et assainir leurs environnements. Si vous utilisez des packages npm dans vos projets JavaScript, je vous recommande de prendre sans attendre les mesures suivantes :
- Identifier les packages à risque : Consultez la liste des modules compromis (par exemple
chalk,debug,ansi-styles,supports-color,strip-ansi,has-ansi,wrap-ansi,color-string, etc.) et vérifiez si votre application ou vos dépendances les utilisent. Les versions malveillantes identifiées portent des numéros spécifiques (ex :chalkv5.6.1,debugv4.4.2, etc. – toutes publiées le 8/09/2025). - Mettre à jour ou rétrograder les versions : Si vous constatez la présence de l’une de ces versions compromises, remplacez-les sans délai. Soit en passant à la version corrigée (après suppression du malware) publiée par le mainteneur légitime, soit en rétrogradant temporairement à la dernière version sûre connue. Npm a retiré de son registre les versions infectées, donc une réinstallation forcée devrait restaurer une version saine.
- Purger le cache et réinstaller : Pour plus de sûreté, videz le cache local de votre gestionnaire de paquets (
npm cache clean --force) et réinstallez vos dépendances depuis zéro. Cela garantira qu’aucun résidu du code malveillant ne subsiste dans vos environnements de build ou de production. - Utiliser des fichiers de lock et des versions figées : Cet incident rappelle l’importance d’avoir un
package-lock.jsonou équivalent afin de figer les versions exactes des dépendances. En verrouillant les versions, vous évitez les mises à jour surprises d’un package vers une version compromise. Bien entendu, cela n’élimine pas le risque (une mise à jour finira par arriver), mais permet de contrôler le moment de la mise à jour et d’auditer les changements avant déploiement. - Vigilance sur les transactions crypto : Si votre application manipule des cryptomonnaies (par exemple intégration d’un wallet ou paiements crypto), soyez particulièrement attentif dans les jours qui viennent. Informez vos utilisateurs de vérifier systématiquement les adresses de destination avant de confirmer une transaction. En interne, envisagez d’inspecter vos logs applicatifs web pour détecter toute anomalie dans les appels réseau ou les transactions durant la période du 8 septembre.
- Sensibilisation des mainteneurs et développeurs : Côté organisation, renforcez la sensibilisation à la sécurité auprès de vos équipes, notamment sur le phishing ciblé. Cet incident est un cas d’école de la manière dont un courriel plausible peut piéger même un mainteneur expérimenté. Rappelez les bonnes pratiques : ne jamais cliquer sur des liens suspects, vérifier l’URL avant de saisir des informations sensibles, et privilégier l’utilisation de clés de sécurité physiques (Yubikey ou autres) pour l’authentification double facteur sur les comptes critiques (GitHub, npm…).
- Renforcer la sécurité de la chaîne d’approvisionnement : Envisagez des outils et procédures pour contrôler les dépendances tierces. Des solutions de détection de malware dans les packages (comme les flux d’intelligence de sécurité, scans automatisés ou outils d’analyse de comportement) peuvent aider à repérer plus vite des modifications suspectes. De plus, la communauté discute de mesures telles qu’une attestation d’origine des builds pour les packages les plus populaires, afin de garantir qu’une publication npm provient bien d’un processus de build légitime et non d’un accès direct malveillant.
La conclusion est que cette « faille npm » très médiatisée agit comme un rappel salutaire : même les projets open source les plus fiables peuvent être compromis à la source. En tant que CISO, analyste SOC ou développeur, il est crucial de rester à l’affût des alertes de sécurité concernant vos outils et bibliothèques, et de réagir promptement pour protéger vos utilisateurs et vos données.
Cette fois-ci, les dégâts ont été contenus et l’attaque visait un objectif financier relativement circonscrit. Mais c’est une piqûre de rappel sur l’importance de la vigilance collective autour de l’écosystème open source et de la nécessité d’outils et de processus renforcés pour sécuriser la chaîne logistique du logiciel.
Enjoy !
Sources
- Aikido Security – « npm debug and chalk packages compromised », article de blog du 8 septembre 2025 par Charlie Eriksen.
- Krebs on Security – « 18 Popular Code Packages Hacked, Rigged to Steal Crypto », article du 8 septembre 2025 par Brian Krebs.
