Le contexte : Injective Labs et l'écosystème DeFi
Injective Labs est l'un des projets phares de la finance décentralisée (DeFi) construits sur l'écosystème Cosmos/IBC. Leur blockchain Layer-1 optimisée pour le trading offre des applications d'échanges décentralisés, de marchés prédictifs et de produits dérivés on-chain. Le SDK TypeScript d'Injective — @injectivelabs/sdk-ts — est la brique fondamentale utilisée par les développeurs pour intégrer leurs applications à la blockchain Injective : gestion de portefeuilles, signature de transactions, interaction avec les smart contracts.
Avec 50 000 téléchargements par semaine sur npm, ce package est un point névralgique de l'écosystème. Des dizaines de protocoles DeFi dépendent directement ou transitivement de @injectivelabs/sdk-ts. Compromettre ce package, c'est obtenir un accès potentiel aux clés privées de milliers de développeurs et d'utilisateurs finaux. C'est exactement ce que les attaquants ont réussi à faire le 8 juillet 2026.
L'écosystème Cosmos/IBC représente plus de 75 blockchains interconnectées avec une valeur totale verrouillée (TVL) dépassant les 10 milliards de dollars. Une compromission du SDK d'Injective n'affecte pas uniquement les utilisateurs directs d'Injective — elle touche potentiellement tout projet qui interagit avec cette blockchain via des ponts inter-chaînes (bridges) ou des agrégateurs DeFi.
💡 Notre avis d'expert
Le risque systémique des packages npm à mainteneur unique dans l'écosystème DeFi est considérable. Un seul dépôt GitHub compromis donne accès à la publication de dizaines de packages sous un même scope npm. Quand ce scope est @injectivelabs avec 50K téléchargements hebdomadaires, la fenêtre d'exploitation est énorme — même si elle ne dure qu'une heure. Les projets DeFi doivent traiter la sécurité de leur supply chain npm avec le même niveau de rigueur que la sécurité de leurs smart contracts.
Anatomie technique de l'attaque
L'attaque contre Injective Labs suit un schéma classique de compromission de supply chain npm, mais son exécution est particulièrement sophistiquée dans la discrétion du payload malveillant.
Compromission du dépôt GitHub
Les attaquants ont d'abord obtenu un accès au dépôt GitHub d'Injective Labs. Le vecteur exact n'a pas été divulgué publiquement à ce jour, mais les hypothèses privilégiées par les chercheurs de StepSecurity incluent : vol de token d'accès personnel (PAT) via un poste de développeur compromis, exploitation d'une faille dans le pipeline CI/CD, ou compromission d'un compte mainteneur via credential stuffing. Une fois dans le dépôt, les attaquants ont modifié le code source et déclenché la publication de versions malveillantes sur npm.
Le faux module de télémétrie
La charge malveillante était dissimulée dans un fichier nommé telemetry.ts — un nom parfaitement anodin dans un SDK. De nombreux packages légitimes incluent des modules de télémétrie pour collecter des métriques d'utilisation anonymisées. C'est cette normalité apparente qui rendait la détection par revue de code humaine particulièrement difficile.
Le module interceptait les appels aux fonctions de gestion de portefeuilles du SDK — spécifiquement les méthodes de signature de transactions et de dérivation de clés. À chaque appel, il capturait silencieusement :
- Les clés privées utilisées pour signer les transactions Injective
- Les seed phrases (mnémoniques) passées aux fonctions de création de portefeuille
- Les clés dérivées générées via le chemin de dérivation HD (BIP-44)
- Les adresses des portefeuilles associées pour permettre un ciblage ultérieur
Exfiltration par HTTP POST
Les données capturées étaient encodées en Base64 puis envoyées via une requête HTTP POST vers un serveur contrôlé par les attaquants. Le payload était formaté pour ressembler à une requête de télémétrie légitime — avec des headers standards Content-Type: application/json et un user-agent imitant les SDKs d'analytics populaires. Cette technique rendait la détection par inspection réseau plus difficile, car le trafic sortant ne présentait pas les signatures habituelles d'exfiltration malveillante.
La version spécifiquement concernée est @injectivelabs/sdk-ts@1.20.21. Les versions antérieures (1.20.20 et inférieures) et la version corrective 1.20.23 ne contiennent pas le code malveillant.
La timeline de l'incident
L'un des aspects les plus remarquables de cet incident est la rapidité de détection et de résolution. Voici le déroulé chronologique reconstitué à partir des rapports de Socket, Ox Security et StepSecurity.
- 8 juillet 2026, 14h32 UTC : publication de
@injectivelabs/sdk-ts@1.20.21sur le registre npm. Le pipeline de publication automatisé du dépôt compromis a été utilisé. - 14h35–14h48 UTC : publication successive de 17 autres packages malveillants sous le scope
@injectivelabs, tous contenant le même module de fausse télémétrie. - 14h51 UTC : l'analyse comportementale de Socket.dev déclenche une alerte automatique. Le système détecte un nouveau module effectuant des requêtes HTTP sortantes vers un domaine inconnu, avec accès aux données sensibles du runtime.
- 14h58 UTC : Ox Security confirme indépendamment la détection via son monitoring de packages npm à haute valeur. Le hashing du bytecode montre des modifications non documentées par rapport à la version précédente.
- 15h04 UTC : StepSecurity publie une alerte via son programme Harden-Runner, signalant des connexions réseau anormales depuis les pipelines CI/CD utilisant les packages @injectivelabs.
- 15h12 UTC : l'équipe Injective Labs est notifiée. La révocation des tokens de publication npm est initiée.
- 15h24 UTC : les 18 versions malveillantes sont dépubliées (unpublished) du registre npm. L'accès au dépôt GitHub est verrouillé, les credentials sont révoqués.
- 15h38 UTC : publication de
@injectivelabs/sdk-ts@1.20.23(version corrective), depuis un environnement sécurisé vérifié.
Temps total entre compromission et résolution : moins d'une heure. C'est exceptionnellement rapide pour un incident de supply chain npm — mais 52 minutes suffisent pour que des milliers de projets installent la version malveillante via leurs pipelines CI/CD automatisés.
💡 Notre avis d'expert
Une détection en moins d'une heure est exceptionnelle pour un incident de supply chain npm. La majorité des compromissions publiées en 2025-2026 restent actives pendant des jours, voire des semaines, avant détection. Ce résultat est dû à la convergence de trois systèmes de monitoring indépendants (Socket, Ox, StepSecurity) qui surveillaient activement les packages DeFi à haute valeur. Cette rapidité ne doit cependant pas devenir un faux sentiment de sécurité — 52 minutes suffisent pour que des centaines de pipelines CI/CD automatiques installent et exécutent le code malveillant. La détection rapide ne remplace pas la prévention.
Les 17 autres packages compromis
L'attaque ne s'est pas limitée à sdk-ts. En 16 minutes (de 14h35 à 14h48 UTC), les attaquants ont publié des versions malveillantes de 17 packages supplémentaires sous le scope @injectivelabs. Cette approche en rafale visait à maximiser la couverture : même si un développeur n'utilisait pas directement sdk-ts, il pouvait être affecté via une dépendance transitive à l'un des autres packages.
Voici la liste complète des packages compromis :
| Package | Téléchargements/semaine | Impact |
|---|---|---|
@injectivelabs/sdk-ts | 50 000 | Critique — SDK principal |
@injectivelabs/wallet-ts | 28 000 | Critique — gestion portefeuilles |
@injectivelabs/chain-api | 22 000 | Élevé |
@injectivelabs/networks | 35 000 | Élevé |
@injectivelabs/utils | 40 000 | Élevé |
@injectivelabs/token-metadata | 18 000 | Modéré |
@injectivelabs/contracts | 12 000 | Modéré |
@injectivelabs/indexer-api | 15 000 | Modéré |
@injectivelabs/bridge-ts | 9 000 | Modéré |
@injectivelabs/staking-ts | 7 000 | Modéré |
@injectivelabs/governance-ts | 5 000 | Modéré |
@injectivelabs/exchange-api | 11 000 | Modéré |
@injectivelabs/explorer-api | 6 000 | Faible |
@injectivelabs/test-utils | 3 000 | Faible |
@injectivelabs/sdk-ui-ts | 8 000 | Modéré |
@injectivelabs/exceptions | 20 000 | Élevé |
@injectivelabs/ts-types | 25 000 | Élevé |
@injectivelabs/mito-ts | 4 000 | Faible |
Le cumul représente plus de 318 000 téléchargements hebdomadaires. Chaque package contenait une variante du même module de fausse télémétrie, adaptée au contexte spécifique du package (interception des fonctions de signature pour wallet-ts, des appels API pour chain-api, etc.).
Ce que ça signifie pour vous
Si vous êtes développeur en France et que vous travaillez sur des projets liés à la blockchain, au Web3, ou simplement que votre arbre de dépendances npm inclut un package de l'écosystème Cosmos/IBC, cet incident vous concerne directement.
Impact direct pour les développeurs Web3 français
La France possède un écosystème Web3 dynamique, avec des hubs significatifs à Paris (Station F, quartier de la Bourse), Lyon, et Bordeaux. De nombreuses startups françaises du Web3 utilisent les SDK des blockchains Cosmos/IBC pour leurs applications DeFi, leurs ponts inter-chaînes, ou leurs agrégateurs. Si l'un de vos projets inclut @injectivelabs/sdk-ts directement ou comme dépendance transitive, vous devez agir immédiatement.
Le problème plus large : la confiance implicite dans npm
Au-delà de l'écosystème Injective spécifiquement, cet incident illustre un problème structurel de npm qui touche tous les développeurs JavaScript/TypeScript. Le registre npm repose sur un modèle de confiance implicite : quand vous exécutez npm install, vous faites confiance à chaque mainteneur de chaque package dans votre arbre de dépendances. Un projet npm moyen possède 200+ dépendances transitives — autant de points d'entrée potentiels pour un attaquant.
L'attaque Injective Labs démontre que même les projets bien établis, avec des milliers d'utilisateurs et une équipe de développement active, peuvent être compromis. La sécurité de votre projet ne dépend pas uniquement de votre propre vigilance — elle dépend de la vigilance de chaque mainteneur en amont de votre supply chain.
💡 Notre avis d'expert
Pour les développeurs français, la sécurité de la supply chain npm doit devenir une compétence fondamentale, au même titre que l'écriture de tests ou la revue de code. Ce n'est plus un sujet réservé aux équipes sécurité des grandes entreprises. Chaque développeur qui exécute un npm install est responsable de la sécurité de sa supply chain. L'outillage existe (Socket, Snyk, npm audit, provenance) — il faut l'intégrer dans chaque pipeline CI/CD sans exception.
Votre projet utilise des dépendances npm DeFi/Web3 ?
D-Open réalise des audits de sécurité supply chain npm spécifiques aux projets crypto et DeFi. Nous analysons votre arbre de dépendances, identifions les packages à risque, configurons le monitoring automatisé et mettons en place les contrôles de sécurité nécessaires pour protéger vos clés et celles de vos utilisateurs.
Demander un audit supply chain npmActions immédiates pour les développeurs
Si vous utilisez des packages @injectivelabs dans vos projets, voici les actions à prendre immédiatement, par ordre de priorité.
1. Vérifier et mettre à jour
Exécutez la commande suivante pour vérifier la version installée de chaque package @injectivelabs dans votre projet :
npm ls @injectivelabs/sdk-ts
# Si la version est 1.20.21, vous êtes affecté.
# Mise à jour immédiate :
npm install @injectivelabs/sdk-ts@1.20.23
# Vérifier TOUS les packages @injectivelabs :
npm ls | grep @injectivelabs2. Rotation de TOUTES les clés
Si la version 1.20.21 a été installée à un moment donné dans votre projet (même brièvement en CI), considérez toutes les clés privées et seed phrases qui ont été utilisées dans cet environnement comme compromises. Cela inclut :
- Les clés privées de portefeuilles Injective
- Les seed phrases utilisées pour dériver des portefeuilles
- Les clés de hot wallets de développement et de test
- Potentiellement les clés de production si elles transitaient par le même environnement
Générez de nouvelles clés, transférez vos fonds, et révoquez les anciennes clés immédiatement.
3. Auditer les dépendances transitives
Même si vous n'utilisez pas directement les packages @injectivelabs, un autre package de votre arbre de dépendances pourrait les inclure transitivement. Utilisez npm audit et vérifiez votre package-lock.json pour identifier toute référence aux versions compromises.
4. Vérifier l'intégrité du lockfile
Comparez votre package-lock.json actuel avec la version en production. Les checksums (integrity hashes) des packages compromis ne correspondront pas à ceux des versions légitimes. Exécutez npm ci (au lieu de npm install) en CI pour garantir que seules les versions vérouillées sont installées.
5. Activer le monitoring continu
Intégrez Socket.dev ou un outil équivalent dans votre pipeline CI/CD. Socket détecte les modifications comportementales suspectes dans les packages npm — exactement le type de détection qui a permis d'identifier l'attaque Injective en 19 minutes.
Leçons structurelles pour la supply chain npm
L'incident Injective Labs n'est pas un cas isolé. Il s'inscrit dans une tendance lourde d'attaques supply chain npm qui s'accélère depuis 2024. Les défenses ponctuelles ne suffisent plus — il faut repenser structurellement la façon dont nous consommons les packages npm.
npm provenance et Sigstore
La fonctionnalité npm provenance, lancée en 2023 et désormais mature, permet de vérifier qu'un package a été publié depuis un environnement CI vérifiable (GitHub Actions, GitLab CI, etc.) via des attestations Sigstore. Si Injective Labs avait activé npm provenance avec des attestations SLSA, les versions publiées depuis un environnement non autorisé auraient été immédiatement identifiables.
La réalité est que, fin juillet 2026, seule une minorité de packages npm activent la provenance. L'adoption reste faible car la configuration n'est pas triviale et les bénéfices ne sont pas immédiatement visibles pour les mainteneurs. C'est pourtant l'une des défenses les plus efficaces contre les compromissions de comptes.
Verrouillage strict et lockfile pinning
L'utilisation systématique de npm ci (au lieu de npm install) en CI/CD est la défense la plus simple et la plus immédiate. Cette commande installe uniquement les versions exactes spécifiées dans le package-lock.json, refusant toute mise à jour automatique. Si un développeur a mis à jour son lockfile avant la détection de l'attaque (par un npm install routinier), la version malveillante peut y être enregistrée. Mais les pipelines CI/CD qui utilisent npm ci avec un lockfile daté d'avant l'attaque ne seront pas affectés.
Intégration de Socket et Snyk
Socket.dev a été le premier à détecter l'anomalie Injective Labs, en 19 minutes. Son approche par analyse comportementale (détection de nouvelles requêtes réseau, accès à des données sensibles, obfuscation de code) est particulièrement efficace contre les attaques zero-day où aucune signature préexistante n'est disponible. Snyk et Grype complètent avec une base de vulnérabilités connues plus large et des capacités de fix automatisé.
L'idéal pour un projet sérieux est de combiner les deux approches : analyse comportementale (Socket) pour les menaces inconnues + base de vulnérabilités (Snyk/Grype) pour les CVE connues. Cette combinaison offre une couverture maximale.
Vers un modèle zero-trust pour npm
L'avenir de la sécurité npm passe par un modèle zero-trust : ne jamais faire confiance à un package uniquement sur la base de son nom ou de sa popularité. Chaque mise à jour doit être vérifiée, chaque nouveau comportement analysé, chaque publication traçée. Les outils existent — le défi est de les intégrer systématiquement dans les workflows de développement sans créer une friction insurmontable.
💡 Notre avis d'expert
L'avenir de la sécurité supply chain npm repose sur les attestations de provenance et Sigstore. Dans 2-3 ans, nous prévoyons que npm rendra la provenance obligatoire pour les packages dépassant un seuil de téléchargements. L'initiative OpenSSF Scorecard fournira un score de sécurité automatisé pour chaque package. Les développeurs qui adoptent ces outils dès maintenant — provenance, Sigstore, SLSA levels — seront en avance quand ces pratiques deviendront obligatoires. N'attendez pas la prochaine attaque pour commencer.
Conclusion
L'attaque contre Injective Labs du 8 juillet 2026 est un cas d'école en matière de supply chain attack npm. Elle démontre que même les projets établis avec des équipes actives peuvent être compromis, que la fenêtre d'exploitation d'une seule heure suffit à mettre en danger des milliers de développeurs et d'utilisateurs, et que seule une défense en profondeur — combinant vérification du lockfile, monitoring comportemental, provenance des packages et rotation proactive des clés — peut réduire le risque à un niveau acceptable.
Pour les développeurs français travaillant dans l'écosystème Web3/DeFi ou simplement dépendant de packages npm à forte valeur, les leçons sont claires : mettez à jour vers @injectivelabs/sdk-ts@1.20.23, effectuez une rotation de toutes les clés potentiellement exposées, et intégrez dès aujourd'hui les outils de détection (Socket, npm audit) dans votre pipeline CI/CD. La sécurité de la supply chain n'est plus un luxe — c'est une nécessité pour tout projet professionnel.
Consultez nos guides détaillés pour une mise en oeuvre concrète : auditer vos dépendances npm, sécuriser vos dépendances, et configurer un pare-feu npm.
Sécurisez votre supply chain npm avec D-Open
Nos experts en sécurité open source accompagnent les équipes de développement françaises dans la mise en place d'une stratégie complète de sécurité supply chain : audit des dépendances, configuration de Socket/Snyk, intégration de npm provenance, formation des équipes. Protégez vos projets avant le prochain incident.
Parler à un expert sécurité supply chainQuestions fréquentes
Qu'est-ce que l'attaque Injective Labs npm de juillet 2026 ?▼
Le 8 juillet 2026, des attaquants ont compromis le dépôt GitHub d'Injective Labs et publié 18 packages npm malveillants sous le scope @injectivelabs. Le package principal, @injectivelabs/sdk-ts version 1.20.21 (50 000 téléchargements/semaine), contenait un faux module de télémétrie qui exfiltrait les clés privées crypto et seed phrases vers un serveur externe via HTTP POST. L'attaque a été détectée en moins d'une heure par Socket, Ox Security et StepSecurity.
Quels packages @injectivelabs ont été compromis ?▼
18 packages au total : sdk-ts, wallet-ts, chain-api, networks, utils, token-metadata, contracts, indexer-api, bridge-ts, staking-ts, governance-ts, exchange-api, explorer-api, test-utils, sdk-ui-ts, exceptions, ts-types et mito-ts. Tous ont reçu une version malveillante contenant le même module de fausse télémétrie exfiltrant les clés privées et seed phrases crypto.
Comment vérifier si mon projet est affecté ?▼
Exécutez npm ls @injectivelabs/sdk-ts pour vérifier la version installée. Si vous avez 1.20.21, mettez immédiatement à jour vers 1.20.23. Vérifiez également votre package-lock.json pour toute référence aux versions compromises des 17 autres packages. Lancez npm audit pour détecter les advisories. Si la version malveillante a été installée, considérez toutes vos clés privées et seed phrases comme compromises et procédez à une rotation immédiate.
Quelles mesures préventives adopter contre les attaques supply chain npm ?▼
Six mesures fondamentales : 1) Utilisez npm ci en CI/CD pour verrouiller les versions via le lockfile. 2) Intégrez Socket.dev pour la détection comportementale des packages malveillants. 3) Activez npm provenance et vérifiez les attestations Sigstore des packages critiques. 4) Générez un SBOM pour inventorier vos dépendances transitives. 5) Mettez en place un pare-feu de dépendances avec une allowlist de packages approuvés. 6) Auditez régulièrement les scripts postinstall et preinstall. Notre guide du pare-feu npm détaille la mise en oeuvre.