Début septembre 2025, le monde de JavaScript a été confronté à l’une des attaques les plus dangereuses de ces dernières années. Les pirates ont eu accès au compte d’un développeur populaire et ont téléchargé sur NPM de nouvelles versions de paquets de base contenant du code malveillant. Ces paquets sont utilisés des milliards de fois chaque semaine, et l’attaque aurait pu entraîner un vol massif auprès des utilisateurs de services de cryptomonnaies.
Heureusement, grâce aux erreurs des hackers et à la réaction rapide de la communauté, les dommages ont été minimes. La rédaction de Quickex a reconstitué la chronologie des événements et expliqué pourquoi tout s’est terminé relativement sans douleur.
Suivez comment le cours du Bitcoin réagit aux chocs du marché avec Quickex.
Comment l’attaque s’est déroulée
Le premier à annoncer ce qui se passait, le soir du 8 septembre, fut Charles Guillaume, CTO de Ledger. Il a averti que le compte d’un développeur connu avait été compromis et que des versions infectées d’outils comme chalk, debug, ansi-styles et strip-ansi avaient été mises en ligne sur NPM. Ces paquets constituent la base de la plupart des applications web, et l’infection menaçait donc l’ensemble de l’écosystème.
Il s’est avéré plus tard que les pirates avaient obtenu l’accès au compte via un e-mail de phishing. Celui-ci imitait un message du support NPM et conduisait vers une fausse page de connexion.
NPM (Node Package Manager) est le plus grand catalogue de paquets pour JavaScript, où les développeurs publient et téléchargent des modules de code prêts à l’emploi. Par exemple, chalk sert à la mise en forme colorée du texte, debug au journal des logs, et ansi-styles et strip-ansi à la gestion des caractères de console. Lorsque les attaquants ont publié les nouvelles versions, celles-ci ont commencé à s’installer automatiquement dans les projets si les développeurs n’avaient pas figé les anciennes.
À mesure que les nouvelles de l’attaque se répandaient, les projets crypto se sont empressés de publier sur leurs réseaux sociaux que l’incident ne les avait pas affectés.
Comment le code malveillant fonctionnait
Le programme intégré agissait comme un crypto-clipper — un type d’attaque qui remplace l’adresse de portefeuille dans une transaction. L’utilisateur croit envoyer des fonds vers son propre compte ou vers un ami, mais en réalité l’argent va à l’adresse de l’attaquant.
StarPlatinum a expliqué en détail la mécanique. Selon lui, le code avait deux modes.
- En mode « passif », il remplaçait les adresses directement dans les interfaces des applications.
- En mode « actif », il interceptait les transactions avant la signature et modifiait les données de destination.
Pour se camoufler, il utilisait l’algorithme de Levenshtein afin de choisir les chaînes les plus proches : les premiers et derniers caractères de l’adresse correspondaient, rendant la substitution presque indétectable.
Il a également cité des comptes précis où les fonds volés devaient être envoyés : le principal, 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976, et plusieurs adresses de réserve.
Au moment de la publication du blogueur, des transferts vers ces portefeuilles avaient été enregistrés, mais les fonds restaient immobiles.
Les développeurs ont découvert le problème pour la première fois lorsque les builds automatiques ont commencé à échouer. Les journaux affichaient des erreurs inhabituelles comme « fetch is not defined ». Une vérification a révélé du code obscurci et des fonctions suspectes liées à Ethereum et Solana.
Pourquoi les dommages ont été minimes
Bien que l’idée de l’attaque semblait dangereuse, en pratique elle n’a pas fonctionné. Le code était trop instable et cassait les processus de build. Cela a permis à la communauté de remarquer rapidement les anomalies et de bloquer les versions infectées.
Charles Guillaume a précisé plus tard que l’attaque avait en fait échoué : il y a eu très peu de victimes. Selon lui, le code malveillant visait les opérations crypto et remplaçait les adresses directement dans les réponses réseau, mais en raison des erreurs des hackers-développeurs, il s’activait de manière imprévisible.
Arkham a estimé que les attaquants n’avaient réussi à voler que 159 $. Cet argent a été envoyé vers les portefeuilles mentionnés dans les rapports de Ledger. Le montant est négligeable par rapport à l’ampleur du risque potentiel, mais l’épisode a montré à quel point l’écosystème était proche d’une crise grave.
Solde du portefeuille crypto des attaquants, selon Arkham
Le rôle des portefeuilles matériels
Les utilisateurs les plus exposés étaient ceux de portefeuilles logiciels qui signent des transactions directement dans le navigateur. Là, le remplacement d’adresse passait presque inaperçu. La situation était très différente pour ceux qui utilisaient des dispositifs matériels pour stocker leurs clés.
Un portefeuille matériel affiche à l’utilisateur toutes les données de la transaction sur son propre écran, et la confirmation se fait via un bouton physique. Même si une application remplaçait l’adresse, l’appareil montrait le véritable destinataire. Un utilisateur attentif remarquera immédiatement l’incohérence et annulera la signature.
Selon Guillaume, des fonctions comme Clear Signing et les vérifications de transaction intégrées font des solutions matérielles une barrière clé contre ce type d’attaques.
Une leçon pour la communauté crypto
Cette histoire rappelle que la vulnérabilité de la chaîne d’approvisionnement reste le principal risque pour l’industrie. Le piratage d’un seul compte de développeur peut mettre en danger des millions d’utilisateurs dans le monde entier.
De toute la situation, trois leçons principales peuvent être retenues :
- Les développeurs doivent figer les versions des dépendances, utiliser des builds reproductibles et vérifier soigneusement les mises à jour des outils de base.
- Les détenteurs de cryptomonnaies doivent conserver leurs actifs dans des portefeuilles matériels et vérifier attentivement les adresses à l’écran de l’appareil avant chaque signature.
Les comptes développeurs dans l’écosystème NPM doivent être protégés par des clés de sécurité et une authentification multifacteur, afin que le phishing ne mène pas à une compromission.
Conclusion
L’attaque contre NPM a montré à quel point toute l’infrastructure peut être fragile : des milliards d’installations dépendaient d’un seul compte. Cette fois, les dommages se sont limités à 159 $, mais la prochaine fois, cela pourrait être différent.
La chance et les erreurs des attaquants ne remplacent pas une sécurité systématique. C’est pourquoi développeurs et utilisateurs doivent prendre des mesures pour que de nouvelles attaques ne les prennent pas par surprise.
Trouvez le meilleur taux de change crypto sur Quickex.