Comment 18 paquets ont été piégés
A 20h24 UTC le 8 juillet 2026, un portefeuille qui a chargé la dernière version de @injectivelabs/sdk-ts a remis en silence sa phrase de récupération a un attaquant. Le premier commit malveillant venait tout juste d'arriver, et il est resté actif environ 49 minutes avant que quelqu'un ne le remarque.
Les attaquants ne sont pas entrés en force. Ils ont utilisé le compte GitHub d'un contributeur de confiance, établi de longue date, pour pousser trois commits qui ont piégé le SDK a la version 1.20.21, ainsi que 17 paquets dependants figés sur cette version exacte. Dix-huit paquets au total portaient le meme poison. La porte dérobée détournait PrivateKey.fromMnemonic() et PrivateKey.fromHex(), de sorte qu'elle exfiltrait les phrases de récupération BIP-39 et les clés privées a l'instant meme ou un portefeuille s'initialisait.
Environ 310 téléchargements ont eu lieu avant que le mainteneur ne le repère, ne revienne en arrière et ne publie une version 1.20.23 saine. Injective Labs affirme qu'aucun fonds d'utilisateur n'a été perdu. La version malveillante a été marquée comme obsolète sur npm plutôt que retirée, elle demeure donc dans le registre comme signal d'alerte.
Le pipeline de confiance était le point faible
La protection résidait dans le mécanisme de livraison. La version malveillante a transité par le propre pipeline de publication de confiance d'Injective Labs sur npm, la voie OIDC concue précisément pour supprimer le risque d'un jeton de publication volé.
C'est la partie dérangeante. La publication de confiance OIDC signifie qu'un paquet peut être publié sans aucun jeton npm de longue durée susceptible d'être volé, ce qui constitue un vrai gain de sécurité. Mais elle signifie aussi qu'un compte humain compromis, associé a une compilation automatisée, transforme cette confiance en voie d'attaque. Il n'y avait aucun jeton a dérober parce que le pipeline lui-meme assurait la signature, et le pipeline se fiait au compte que GitHub déclarait légitime.
Ce qu'il faut vérifier dans vos propres dépendances
La leçon est ici générale, et non propre aux cryptomonnaies. Tout responsable qui publie du logiciel hérite exactement de cette exposition via les dépendances transitives, ces paquets dont vos paquets dépendent et que vous n'avez jamais choisi d'installer directement.
Figez vos dépendances transitives sur des versions réputées saines et analysez-les, afin qu'un remplacement en cours de route sur une version figée apparaisse comme un changement plutôt que de passer inapercu. Considérez l'automatisation de l'éditeur de confiance comme la réduction d'un risque, non comme la suppression de tous, car la voie du compte humain compromis reste ouverte. Et renouvelez tout secret, clé ou identifiant passé par une compilation désormais suspecte, en partant du principe qu'il a été vu.
À lire ensuite: Progress dit aux clients ShareFile d'éteindre | Une faille de Defender donne le contrôle total du PC
