On July 8, 2026, at 20:24 UTC, a single commit landed on the master branch of Injective Labs' injective-ts monorepo. It added what looked like an innocuous telemetry module — a docblock claiming it measured "key derivation methods and timing". Thirty-five minutes later, GitHub Actions had published version 1.20.21 of 18 @injectivelabs npm packages, every one of them carrying a backdoor that captured raw BIP-39 seed phrases and private keys the moment a wallet was loaded (Source: Datadog Security Labs / StepSecurity, July 2026).
The malicious release was live for roughly 49 minutes before the code was reverted and a clean version shipped — fast enough that, by public accounts, no funds were confirmed stolen (Source: Crypto Briefing / BleepingComputer, July 2026). But the incident is a near-perfect case study of where npm supply chain attacks are heading in H2 2026: a compromised maintainer GitHub account, malicious code disguised as legitimate engineering, CI/CD automation amplifying one commit into 18 poisoned packages, and exfiltration hidden inside ordinary-looking HTTP traffic. This article breaks down the full attack chain, the same-week fake payment SDK campaign targeting Paysafe, Skrill and Neteller developers, and what web3 and fintech teams should change now.
The Incident at a Glance
@injectivelabs/sdk-ts is the core TypeScript SDK for building on the Injective blockchain — wallets, trading bots, decentralized exchanges, DeFi applications and payment tools all flow through it. At roughly 50,000 weekly downloads, a poisoned release does not need to run for long to reach sensitive targets (Source: BleepingComputer, July 2026).
The Timeline: One Month of Quiet Reconnaissance
This was not a smash-and-grab. According to StepSecurity's reconstruction of the repository history, suspicious activity started a full month earlier (Source: StepSecurity, July 2026):
June 8, 2026: commits from a compromised GitHub account appear, likely testing access and permissions — including a branch bluntly named test-backdoor-check. Nobody noticed.
July 8, 20:24 UTC: the first malicious commit (0121928) lands on master, adding "key-derivation-telemetry" code to packages/sdk-ts/src/core/accounts/PrivateKey.ts (Source: Datadog Security Labs).
July 8, 20:48 UTC: a second commit applies cosmetic reformatting — noise to blur the diff.
July 8, 20:54 UTC: the version-bump commit triggers the GitHub Actions release workflow.
July 8, 20:59:17–21:00:39 UTC: all 18 @injectivelabs packages are published to npm at version 1.20.21 — 82 seconds from first publish to last (Source: StepSecurity).
July 8, ~21:18 UTC: Socket, OX Security and StepSecurity flag the release; the Injective team reverts the commit and publishes the clean version 1.20.23 within the hour (Source: Crypto Briefing / SC Media, July 2026).
Why this matters
The attacker did not compromise npm. They compromised one GitHub account — and the project's own CI/CD pipeline did the rest, faithfully signing and publishing 18 malicious packages in under two minutes. Release automation is a force multiplier for whoever controls the repository.
The Backdoor: "Telemetry" That Steals Seed Phrases
The malicious module was engineered to survive code review at a glance. The new PrivateKey.ts file carried a professional docblock describing anonymous collection of "key derivation methods and timing" — plausible engineering telemetry for an SDK team. The actual, obfuscated logic did something else entirely (Source: Datadog Security Labs, July 2026):
1. Hook the key-derivation entry points. The code wrapped the two functions every wallet integration passes through — PrivateKey.fromMnemonic() and PrivateKey.fromHex() — capturing raw BIP-39 mnemonic seed phrases and hex private keys at the exact moment a wallet is created or loaded.
2. Encode and smuggle. Captured secrets were base64-encoded and placed inside the X-Request-Id HTTP header of outbound requests — a header that looks like routine request tracing to any network monitor or egress proxy.
3. Exfiltrate to a look-alike endpoint. The destination was disguised as a legitimate Injective testnet archival gRPC-Web service: testnet.archival.chain.grpc-web.injective[.]network. Traffic to an *.injective.network-style domain from an Injective SDK raises no eyebrows (Source: Datadog Security Labs).
Because the hook fires at runtime, inside legitimate application code paths, none of the classic install-time defenses apply. npm v12's default script blocking, --ignore-scripts, allowlists — all irrelevant. The malicious code executes when your application calls the SDK, exactly as designed. The only signals available were the anomalous commit, the version jump, and the outbound traffic pattern.
The Amplifier: 17 Sibling Packages Pinned to the Poisoned Version
The attacker did not stop at sdk-ts. The same release wave published version 1.20.21 across 17 additional @injectivelabs scoped packages that depend on and pin the SDK, meaning developers who never installed sdk-ts directly could still pull the backdoor transitively (Source: BleepingComputer, July 2026). StepSecurity flagged 87 downstream dependent packages that could theoretically have been exposed through this transitive path (Source: StepSecurity).
This is the structural lesson: in a monorepo with automated releases, the blast radius of one compromised account is the entire package scope. If your lockfile resolves any @injectivelabs/* package, the question is not "did I install sdk-ts?" — it is "did anything in my tree resolve to 1.20.21 between 20:59 and 21:48 UTC on July 8?"
Same Week, Same Target Profile: 17 Fake Payment SDKs
One day before the Injective compromise, on July 7, 2026, Socket's scanner detected a coordinated cluster of 17 malicious packages — 13 on npm and 4 on PyPI — impersonating official SDKs for Paysafe, Skrill and Neteller (Source: Socket Threat Research / BleepingComputer, July 2026). Different actor, different technique, identical target profile: developers who handle money.
The craftsmanship was in the camouflage. Instead of calling the real payment APIs, the fake SDKs immediately returned simulated success responses — so a developer wiring up a test integration saw everything "work" while the malware ran in the background. The payloads harvested environment variables including PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN and NPM_TOKEN from developer machines and CI runners, exfiltrating to a command-and-control server hidden behind a three-step decoding scheme (XOR, character shifting, string reversal) and an Ngrok-fronted endpoint (Source: Socket Threat Research, July 2026).
Each npm package shipped versions 1.0.0 through 1.0.3 and was flagged as malware within roughly 6 minutes of publication — but the campaign's cross-registry design (npm + PyPI simultaneously) shows attackers systematically hedging against single-ecosystem detection (Source: Socket Threat Research).
Why Crypto & Fintech Developers Are the 2026 Target
The Injective and payment SDK incidents are not isolated. They sit inside a sustained shift of npm supply chain attacks toward wallets, keys and payment credentials:
September 2025: the chalk/debug compromise injected crypto-draining malware into packages totaling 2.6 billion weekly downloads — still the highest-reach wallet-targeting attack on record (Source: Palo Alto Networks / Mend, 2025).
May 2026: the TrapDoor campaign hit 34 packages across npm, PyPI and Crates.io with a crypto stealer that also poisoned AI assistant config files (Source: Socket, May 2026).
June 2026: the IronWorm campaign targeted web3 developers through compromised npm packages (Source: CryptoTimes, June 2026), and Group-IB counts over 800 packages linked to North Korea's Lazarus group, 97% of them on npm, with wallet theft as a primary funding objective (Source: Group-IB, 2026).
H1 2026 overall: 37 distinct supply chain campaigns and 497 malicious packages were indexed — 4.5 times the total for all of 2025 (Source: Phoenix Security / Sonatype, 2026). For the full picture, see our H1 2026 npm supply chain retrospective.
The economics are simple: a stolen GITHUB_TOKEN must be monetized through further intrusion; a stolen BIP-39 seed phrase is money. SDKs that touch key material are now the highest-value real estate on npm.
Defense Guide: What Actually Protects You
1. Pin exact versions and enforce a cooldown. The malicious 1.20.21 was live for 49 minutes. Teams using a minimum release age (pnpm 11's minimumReleaseAge defaults to 24 hours; Bun and Renovate offer equivalents) never resolved it. If you install packages the moment they publish, you are volunteering to be the detection layer.
2. Audit your lockfile, not just your direct dependencies. 17 of the 18 poisoned packages reached victims transitively through pinned internal dependencies. Run npm ls @injectivelabs/sdk-ts-style queries in CI, and diff lockfiles on every PR — a version jump across an entire scope in one commit is a red flag. Our guide on npm lockfile security covers the CI patterns.
3. Treat key material as radioactive in dependencies. If a dependency update touches code paths that handle mnemonics or private keys — like a new "telemetry" module in PrivateKey.ts — that diff deserves a human review, no matter how legitimate the docblock reads. For wallet builders: derive keys in an isolated process or hardware module so that a compromised SDK never sees raw seed phrases.
4. Monitor egress, including headers. The exfiltration hid in X-Request-Id headers to a look-alike domain. Egress allowlists at the domain level would have caught testnet.archival.chain.grpc-web.injective[.]network — a host that legitimate SDK versions never contacted. In CI, tools that baseline expected network destinations (as StepSecurity's Harden-Runner does) turn this class of exfiltration into an alert.
5. Lock down release automation. The attacker turned GitHub Actions into their distribution channel. Require environment protection rules and a manual approval gate on publish workflows, restrict who can push to release branches, and alert on publishes triggered outside expected patterns. One compromised account should not equal 18 published packages in 82 seconds.
6. Get alerted when a package you ship is flagged. The window between "malicious version published" and "advisory issued" is where the damage happens. Continuous lockfile monitoring — matching what you actually deploy against OSV and advisory feeds daily — shrinks your exposure from weeks to hours.
Frequently Asked Questions
Am I affected by the Injective npm compromise?
Check whether any @injectivelabs package in your dependency tree resolved to version 1.20.21 (published July 8, 2026, ~21:00 UTC). If yes: upgrade to 1.20.23 or later, and treat every private key or mnemonic that passed through the affected code as compromised — rotate wallets and move funds. Remember to check transitive dependencies, not just package.json.
Was any cryptocurrency actually stolen?
No losses were publicly confirmed. The malicious version was live for roughly 49 minutes before Injective reverted it, and the team reported zero user impact. But exfiltrated seed phrases can be used weeks later — anyone who loaded a wallet through v1.20.21 should rotate keys regardless.
How did the attacker get in?
Through a compromised GitHub account of a trusted developer. Reconnaissance commits appeared a month earlier (June 8), including a test branch named test-backdoor-check. Once the attacker could push to master, the project's own GitHub Actions release pipeline published the backdoored packages automatically.
Why didn't npm v12's script blocking stop this?
Because the backdoor never used install scripts. It lived inside the SDK's legitimate runtime code path — the PrivateKey class itself — and executed when applications called it. Install-time defenses (script blocking, --ignore-scripts, allowlists) do not apply to malicious code in the module you deliberately import.
What is the connection with the fake Paysafe/Skrill/Neteller packages?
No attribution links the two campaigns. But both surfaced the same week (July 7–8, 2026) and both target the same profile: developers whose environments contain money-adjacent secrets — wallet keys, payment API credentials, cloud tokens. Financially-focused developer targeting is the defining npm trend of mid-2026.
Monitor your dependencies automatically
CVE OptiBot scans your lockfiles daily and alerts you when a malicious or vulnerable package version appears in a project you actually ship — including transitive dependencies like the 17 pinned @injectivelabs packages. No code access required.
Start free monitoringFurther reading
Le 8 juillet 2026 à 20h24 UTC, un unique commit atterrit sur la branche master du monorepo injective-ts d'Injective Labs. Il ajoutait ce qui ressemblait à un module de télémétrie anodin — un docblock affirmant mesurer « les méthodes et le timing de dérivation de clés ». Trente-cinq minutes plus tard, GitHub Actions avait publié la version 1.20.21 de 18 packages npm @injectivelabs, chacun porteur d'une backdoor capturant les phrases mnémoniques BIP-39 brutes et les clés privées au moment même du chargement d'un wallet (Source : Datadog Security Labs / StepSecurity, juillet 2026).
La release malveillante est restée en ligne environ 49 minutes avant que le code ne soit réverté et qu'une version propre ne soit publiée — assez vite pour qu'aucune perte de fonds n'ait été confirmée publiquement (Source : Crypto Briefing / BleepingComputer, juillet 2026). Mais l'incident est un cas d'école quasi parfait de la direction que prennent les attaques supply chain npm au S2 2026 : compte GitHub de mainteneur compromis, code malveillant déguisé en ingénierie légitime, automatisation CI/CD amplifiant un commit en 18 packages empoisonnés, et exfiltration cachée dans du trafic HTTP d'apparence ordinaire. Cet article décompose la chaîne d'attaque complète, la campagne de faux SDKs de paiement (Paysafe, Skrill, Neteller) de la même semaine, et ce que les équipes web3 et fintech doivent changer dès maintenant.
L'incident en un coup d'œil
@injectivelabs/sdk-ts est le SDK TypeScript central pour développer sur la blockchain Injective — wallets, bots de trading, exchanges décentralisés, applications DeFi et outils de paiement passent tous par lui. Avec environ 50 000 téléchargements hebdomadaires, une release empoisonnée n'a pas besoin de rester longtemps en ligne pour atteindre des cibles sensibles (Source : BleepingComputer, juillet 2026).
La chronologie : un mois de reconnaissance silencieuse
Ce n'était pas un casse improvisé. D'après la reconstruction de l'historique du dépôt par StepSecurity, l'activité suspecte a démarré un mois entier plus tôt (Source : StepSecurity, juillet 2026) :
8 juin 2026 : des commits d'un compte GitHub compromis apparaissent, probablement pour tester les accès et permissions — dont une branche sobrement nommée test-backdoor-check. Personne ne l'a remarqué.
8 juillet, 20h24 UTC : le premier commit malveillant (0121928) atterrit sur master, ajoutant du code de « key-derivation-telemetry » dans packages/sdk-ts/src/core/accounts/PrivateKey.ts (Source : Datadog Security Labs).
8 juillet, 20h48 UTC : un second commit applique un reformatage cosmétique — du bruit pour brouiller le diff.
8 juillet, 20h54 UTC : le commit de montée de version déclenche le workflow de release GitHub Actions.
8 juillet, 20h59:17–21h00:39 UTC : les 18 packages @injectivelabs sont publiés sur npm en version 1.20.21 — 82 secondes entre la première et la dernière publication (Source : StepSecurity).
8 juillet, ~21h18 UTC : Socket, OX Security et StepSecurity signalent la release ; l'équipe Injective réverte le commit et publie la version propre 1.20.23 dans l'heure (Source : Crypto Briefing / SC Media, juillet 2026).
Pourquoi c'est important
L'attaquant n'a pas compromis npm. Il a compromis un seul compte GitHub — et le pipeline CI/CD du projet lui-même a fait le reste, signant et publiant fidèlement 18 packages malveillants en moins de deux minutes. L'automatisation des releases est un multiplicateur de force pour quiconque contrôle le dépôt.
La backdoor : une « télémétrie » qui vole les seed phrases
Le module malveillant était conçu pour survivre à une revue de code rapide. Le nouveau fichier PrivateKey.ts portait un docblock professionnel décrivant une collecte anonyme des « méthodes et du timing de dérivation de clés » — de la télémétrie d'ingénierie plausible pour une équipe SDK. La logique réelle, obfusquée, faisait tout autre chose (Source : Datadog Security Labs, juillet 2026) :
1. Hooker les points d'entrée de dérivation de clés. Le code enveloppait les deux fonctions par lesquelles passe toute intégration wallet — PrivateKey.fromMnemonic() et PrivateKey.fromHex() — capturant les phrases mnémoniques BIP-39 brutes et les clés privées hexadécimales au moment exact de la création ou du chargement d'un wallet.
2. Encoder et dissimuler. Les secrets capturés étaient encodés en base64 et placés dans le header HTTP X-Request-Id des requêtes sortantes — un header qui ressemble à du traçage de requêtes routinier pour n'importe quel moniteur réseau ou proxy de sortie.
3. Exfiltrer vers un endpoint sosie. La destination se faisait passer pour un service gRPC-Web d'archivage testnet Injective légitime : testnet.archival.chain.grpc-web.injective[.]network. Du trafic vers un domaine de type *.injective.network émis par un SDK Injective n'éveille aucun soupçon (Source : Datadog Security Labs).
Parce que le hook se déclenche à l'exécution, dans les chemins de code légitimes de l'application, aucune des défenses classiques à l'installation ne s'applique. Le blocage des scripts par défaut de npm v12, --ignore-scripts, les allowlists — tout cela est hors sujet. Le code malveillant s'exécute quand votre application appelle le SDK, exactement comme prévu. Les seuls signaux disponibles étaient le commit anormal, le saut de version et le pattern de trafic sortant.
L'amplificateur : 17 packages frères épinglés sur la version empoisonnée
L'attaquant ne s'est pas arrêté à sdk-ts. La même vague de release a publié la version 1.20.21 sur 17 packages @injectivelabs supplémentaires qui dépendent du SDK et l'épinglent, ce qui signifie que des développeurs n'ayant jamais installé sdk-ts directement pouvaient quand même récupérer la backdoor de manière transitive (Source : BleepingComputer, juillet 2026). StepSecurity a identifié 87 packages dépendants downstream théoriquement exposés par ce chemin transitif (Source : StepSecurity).
C'est la leçon structurelle : dans un monorepo avec releases automatisées, le rayon d'impact d'un seul compte compromis est le scope de packages entier. Si votre lockfile résout n'importe quel package @injectivelabs/*, la question n'est pas « ai-je installé sdk-ts ? » — c'est « quelque chose dans mon arbre a-t-il résolu la 1.20.21 entre 20h59 et 21h48 UTC le 8 juillet ? »
Même semaine, même profil de cible : 17 faux SDKs de paiement
Un jour avant la compromission Injective, le 7 juillet 2026, le scanner de Socket a détecté un cluster coordonné de 17 packages malveillants — 13 sur npm et 4 sur PyPI — imitant les SDKs officiels de Paysafe, Skrill et Neteller (Source : Socket Threat Research / BleepingComputer, juillet 2026). Acteur différent, technique différente, profil de cible identique : les développeurs qui manipulent de l'argent.
Le savoir-faire résidait dans le camouflage. Au lieu d'appeler les vraies APIs de paiement, les faux SDKs renvoyaient immédiatement des réponses de succès simulées — un développeur câblant une intégration de test voyait tout « fonctionner » pendant que le malware tournait en arrière-plan. Les payloads moissonnaient les variables d'environnement, dont PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN et NPM_TOKEN, sur les postes développeurs et les runners CI, avec exfiltration vers un serveur de commande et contrôle dissimulé derrière un schéma de décodage en trois étapes (XOR, décalage de caractères, inversion de chaîne) et un endpoint frontal Ngrok (Source : Socket Threat Research, juillet 2026).
Chaque package npm publiait les versions 1.0.0 à 1.0.3 et a été signalé comme malveillant en environ 6 minutes — mais la conception multi-registres de la campagne (npm + PyPI simultanément) montre que les attaquants se couvrent systématiquement contre la détection mono-écosystème (Source : Socket Threat Research).
Pourquoi les développeurs crypto & fintech sont la cible de 2026
Les incidents Injective et faux SDKs de paiement ne sont pas isolés. Ils s'inscrivent dans un basculement durable des attaques supply chain npm vers les wallets, les clés et les credentials de paiement :
Septembre 2025 : la compromission chalk/debug a injecté un crypto-drainer dans des packages totalisant 2,6 milliards de téléchargements hebdomadaires — toujours l'attaque ciblant les wallets à la plus grande portée jamais enregistrée (Source : Palo Alto Networks / Mend, 2025).
Mai 2026 : la campagne TrapDoor a touché 34 packages sur npm, PyPI et Crates.io avec un crypto stealer qui empoisonnait aussi les fichiers de config d'assistants IA (Source : Socket, mai 2026).
Juin 2026 : la campagne IronWorm a ciblé les développeurs web3 via des packages npm compromis (Source : CryptoTimes, juin 2026), et Group-IB recense plus de 800 packages liés au groupe Lazarus (Corée du Nord), dont 97% sur npm, avec le vol de wallets comme objectif de financement principal (Source : Group-IB, 2026).
S1 2026 dans son ensemble : 37 campagnes supply chain distinctes et 497 packages malveillants ont été indexés — 4,5 fois le total de toute l'année 2025 (Source : Phoenix Security / Sonatype, 2026). Pour la vue d'ensemble, consultez notre rétrospective supply chain npm S1 2026.
L'économie est simple : un GITHUB_TOKEN volé doit être monétisé par une intrusion supplémentaire ; une seed phrase BIP-39 volée est de l'argent. Les SDKs qui touchent au matériel cryptographique sont désormais le terrain le plus convoité de npm.
Guide de défense : ce qui vous protège réellement
1. Épinglez des versions exactes et imposez un délai de carence. La 1.20.21 malveillante est restée en ligne 49 minutes. Les équipes utilisant un âge minimum de release (le minimumReleaseAge de pnpm 11 est à 24 heures par défaut ; Bun et Renovate offrent des équivalents) ne l'ont jamais résolue. Si vous installez les packages à la seconde où ils sont publiés, vous vous portez volontaire comme couche de détection.
2. Auditez votre lockfile, pas seulement vos dépendances directes. 17 des 18 packages empoisonnés atteignaient leurs victimes de manière transitive via des dépendances internes épinglées. Lancez des requêtes de type npm ls @injectivelabs/sdk-ts en CI, et diffez les lockfiles à chaque PR — un saut de version sur un scope entier en un seul commit est un signal d'alerte. Notre guide sur la sécurité des lockfiles npm couvre les patterns CI.
3. Traitez le matériel cryptographique comme radioactif dans les dépendances. Si une mise à jour de dépendance touche des chemins de code manipulant mnémoniques ou clés privées — comme un nouveau module « télémétrie » dans PrivateKey.ts — ce diff mérite une revue humaine, quelle que soit la légitimité apparente du docblock. Pour les créateurs de wallets : dérivez les clés dans un processus isolé ou un module matériel, afin qu'un SDK compromis ne voie jamais les seed phrases brutes.
4. Surveillez le trafic sortant, headers compris. L'exfiltration se cachait dans des headers X-Request-Id vers un domaine sosie. Des allowlists de sortie au niveau domaine auraient intercepté testnet.archival.chain.grpc-web.injective[.]network — un hôte que les versions légitimes du SDK ne contactaient jamais. En CI, les outils qui établissent une baseline des destinations réseau attendues (comme Harden-Runner de StepSecurity) transforment cette classe d'exfiltration en alerte.
5. Verrouillez l'automatisation des releases. L'attaquant a transformé GitHub Actions en canal de distribution. Exigez des règles de protection d'environnement et une validation manuelle sur les workflows de publication, restreignez qui peut pousser sur les branches de release, et alertez sur les publications déclenchées hors des patterns attendus. Un compte compromis ne devrait pas équivaloir à 18 packages publiés en 82 secondes.
6. Soyez alerté quand un package que vous déployez est signalé. La fenêtre entre « version malveillante publiée » et « advisory émis » est là où les dégâts se produisent. Le monitoring continu des lockfiles — confronter quotidiennement ce que vous déployez réellement aux flux OSV et advisories — réduit votre exposition de semaines à quelques heures.
Questions fréquentes
Suis-je affecté par la compromission npm Injective ?
Vérifiez si un package @injectivelabs de votre arbre de dépendances a résolu la version 1.20.21 (publiée le 8 juillet 2026 vers 21h00 UTC). Si oui : passez en 1.20.23 ou ultérieure, et considérez comme compromise toute clé privée ou mnémonique passée par le code affecté — faites tourner vos wallets et déplacez les fonds. Pensez à vérifier les dépendances transitives, pas seulement le package.json.
Des cryptomonnaies ont-elles réellement été volées ?
Aucune perte n'a été confirmée publiquement. La version malveillante est restée en ligne environ 49 minutes avant qu'Injective ne la réverte, et l'équipe a rapporté zéro impact utilisateur. Mais des seed phrases exfiltrées peuvent être utilisées des semaines plus tard — quiconque a chargé un wallet via la v1.20.21 devrait faire tourner ses clés malgré tout.
Comment l'attaquant est-il entré ?
Via le compte GitHub compromis d'un développeur de confiance. Des commits de reconnaissance sont apparus un mois plus tôt (8 juin), dont une branche de test nommée test-backdoor-check. Une fois capable de pousser sur master, l'attaquant a laissé le pipeline de release GitHub Actions du projet publier automatiquement les packages backdoorés.
Pourquoi le blocage des scripts de npm v12 n'a-t-il pas arrêté cette attaque ?
Parce que la backdoor n'utilisait aucun script d'installation. Elle vivait dans le chemin de code runtime légitime du SDK — la classe PrivateKey elle-même — et s'exécutait quand les applications l'appelaient. Les défenses à l'installation (blocage de scripts, --ignore-scripts, allowlists) ne s'appliquent pas au code malveillant du module que vous importez délibérément.
Quel est le lien avec les faux packages Paysafe/Skrill/Neteller ?
Aucune attribution ne relie les deux campagnes. Mais les deux ont émergé la même semaine (7-8 juillet 2026) et ciblent le même profil : les développeurs dont l'environnement contient des secrets liés à l'argent — clés de wallets, credentials d'APIs de paiement, tokens cloud. Le ciblage des développeurs à but financier est la tendance npm marquante de la mi-2026.
Surveillez vos dépendances automatiquement
CVE OptiBot scanne vos lockfiles chaque jour et vous alerte quand une version de package malveillante ou vulnérable apparaît dans un projet que vous déployez réellement — y compris les dépendances transitives comme les 17 packages @injectivelabs épinglés. Aucun accès à votre code requis.
Démarrer le monitoring gratuitÀ lire ensuite