Un paquet npm qui volait les clés privées
Un paquet npm comptant environ 50 000 téléchargements hebdomadaires a envoyé les clés privées de ses utilisateurs pendant une courte période. Le SDK officiel Injective contenait une fonction déguisée en télémétrie qui collectait les clés de portefeuille et les mnémotechniques. C’est le service de sécurité Socket qui l’a découvert. L’affaire montre comment une seule dépendance compromise peut empoisonner tout un processus de construction.
Les points clés en bref
- Un paquet, de nombreuses victimes. Le @injectivelabs/sdk-ts compromis collectait les clés privées et les mnémotechniques et se propageait via 17 paquets dépendants.
- Déguisé en télémétrie. La fonction malveillante codait les données en base64 et les envoyait silencieusement à un point de terminaison dissimulé.
- Bien au-delà de la crypto. Tout processus de construction qui tire des dépendances sans les vérifier comporte le même risque. Le verrouillage, la vérification de signature et la rotation rapide sont la réponse.
Voir aussi : Un pilote signé rend la protection des points de terminaison aveugle · Lorsque les attaquants sont plus rapides que le correctif
Ce qui se cachait dans le SDK Injective
Qu’est-ce qu’une attaque de la chaîne d’approvisionnement ? Une attaque de la chaîne d’approvisionnement ne vise pas directement une entreprise, mais une composante que de nombreuses entreprises intègrent. Lorsqu’une dépendance publique est compromise, le code malveillant se propage via le canal d’installation normal à tous ceux qui téléchargent le paquet.
Dans le cas présent, il s’agissait de la bibliothèque TypeScript @injectivelabs/sdk-ts, un outil pour les applications autour de la blockchain Injective. Une version compromise introduisait une fonction qui se présentait comme une télémétrie. En réalité, elle collectait des données d’accès. L’appel pour dériver un portefeuille à partir d’une mnémotechnique enregistrait la phrase complète, l’appel à partir d’une clé privée enregistrait son contenu.
Les données collectées étaient codées en base64 et envoyées silencieusement via une requête réseau à un point de terminaison dissimulé. Pour le développeur, le processus restait invisible. Le paquet compte environ 50 000 téléchargements par semaine. La version compromise a été propagée via 17 autres paquets Injective. Quiconque en a inclus un était affecté, sans avoir jamais installé directement la bibliothèque.
Comment la faille est entrée dans le code
Le chemin d’accès se faisait via le projet officiel lui-même. La fonction malveillante est arrivée via des commits dans le référentiel GitHub, effectués via un compte avec une longue historique de contributions. Un tel compte ne suscite pas de suspicion. C’est précisément cela qui rend la prise de contrôle d’un contributeur établi si efficace.
Le processus était manifeste. Des semaines avant la publication, un branche de test est apparu dans le référentiel avec un nom évocateur d’un test de porte dérobée. De telles traces sont évidentes a posteriori, mais facilement négligées dans la vie quotidienne d’un projet open source actif.
Pourquoi cela concerne chaque processus de construction
L’incident porte une étiquette crypto, mais le modèle est universel. Chaque application moderne tire des dizaines à des centaines de paquets étrangers, souvent sur plusieurs niveaux. Une seule liaison compromise suffit. Ensuite, le code malveillant s’exécute avec les droits du processus de construction.
Les dépendances transitives sont particulièrement problématiques. Une équipe intègre consciemment un paquet et hérite de toute sa chaîne, qu’elle n’a jamais vérifiée. Quiconque conserve des données d’accès, des jetons ou des clés dans un environnement de développement avec des dépendances non vérifiées donne à une telle attaque exactement ce qu’elle cherche.
Que doivent faire les développeurs et les équipes de sécurité en maintenant
La première question est la suivante : une version affectée est-elle en cours d’exécution dans votre propre infrastructure ? Sans inventaire de dépendances fiable, la réponse reste une devinette. Ce n’est qu’après cela que les leviers techniques peuvent être actionnés.
Vérifier immédiatement
- ✓Détecter la version SDK affectée dans tous les projets, les inclusions directes et transitives, puis passer à la version corrigée.
- ✓Traiter toutes les clés et les mnémotechniques qui ont traversé une version affectée comme compromises, les faire tourner et déplacer les crédits.
- ✓Épingler fermement les dépendances via les fichiers de verrouillage et adopter les mises à jour de manière consciente plutôt qu’automatique.
- ✓Vérifier les preuves d’origine (provenance npm) et les signatures de packages, ainsi que maintenir un inventaire logiciel (SBOM).
- ✓Ne pas stocker de secrets de longue durée dans les environnements de construction avec des dépendances non vérifiées, et restreindre les droits dans le système CI/CD.
Les outils d’analyse de dépendances réduisent le temps de réaction, car ils signalent un package compromis avant qu’il ne soit largement déployé. Mais le véritable levier reste organisationnel : qui ne connaît pas sa chaîne d’approvisionnement ne peut pas la protéger.
Un cas de test pour la chaîne d’approvisionnement
Injective a déclaré avoir résolu l’incident en moins d’une heure et n’avoir pas nui à aucun utilisateur. Cette évaluation provient du fournisseur lui-même. Indépendamment de cela, la leçon reste valable : la réaction rapide d’un projet n’exonère pas les utilisateurs de sécuriser leur propre chaîne.
Pour les entreprises ayant des obligations au titre de NIS2 ou de DORA, le risque lié à la chaîne d’approvisionnement n’est plus un sujet abstrait. Les deux cadres exigent que les organisations gèrent les risques liés à leurs fournisseurs et composants. Un package compromis dans votre propre processus de construction est exactement le cas pour lequel ces exigences ont été écrites.
Foire aux questions
Chaque question est fermée. Un clic déverrouille la réponse.
Qu’est-ce qu’une attaque de la chaîne d’approvisionnement ?
Une attaque de la chaîne d’approvisionnement manipule un composant partagé par de nombreuses cibles, comme une dépendance logicielle publique. Le code malveillant se propage alors via le chemin d’installation normal à tous ceux qui intègrent le paquet.
Suis-je affecté si je n’ai jamais installé directement le SDK ?
Possible. La version manipulée a été distribuée via 17 autres paquets. Quiconque en a intégré un a hérité de la dépendance de manière transitive, sans jamais avoir directement téléchargé la bibliothèque elle-même.
La mise à jour vers la version corrigée suffit-elle ?
Comme première étape, oui, mais pas comme seule mesure. Les clés et les mnémotechniques qui ont été utilisées avec une version affectée sont considérées comme compromises. Elles doivent être rotées et les soldes doivent être déplacées.
Comment le code malveillant a-t-il pu pénétrer dans un projet officiel ?
Via des commits effectués à partir d’un compte avec une longue historique de contributions dans le référentiel officiel. Un contributeur établi ne suscite pas de suspicion, ce qui rend la prise de contrôle d’un tel compte particulièrement efficace.
Qu’est-ce qui protège le plus efficacement contre de telles attaques ?
Un inventaire de dépendances connu, des fichiers de verrouillage fixes, des preuves d’origine vérifiées et des signatures, ainsi que des droits strictement limités dans la construction. De plus, pas de secrets persistants dans les environnements avec des dépendances non vérifiées.
Conseils de lecture de la rédaction
Conseil de lectureVol de jeton OAuth : comment les attaquants contournent MFAConseil de lectureComment fonctionne une attaque de ransomwareConseil de lectureCe qui distingue vraiment EDR et XDR
Plus d’informations sur le réseau MBF Media
cloudmagazinPour la première fois, on peut observer une intelligence artificielle en train de réfléchirMyBusinessFutureIntelligence artificielle dans les PME : du pilotage à la mise à l’échelleDigital ChiefsLa direction informatique détermine si le spin-off est rentable
Source de l’image : générée par IA (juillet 2026)
