Skip to content

Back to the catalog

Compromised Injective SDK npm Package Exfiltrates Wallet Keys and Mnemonics
socket.devadvisory

Compromised Injective SDK npm Package Exfiltrates Wallet Keys and Mnemonics

Socket details a compromise of @injectivelabs/sdk-ts version 1.20.21 (a popular Injective Labs TypeScript SDK with ~50,000 weekly downloads), in which the fromMnemonic and fromHex key-derivation functions were hooked with a trackKeyDerivation call that base64-encodes and exfiltrates wallet private keys and mnemonic phrases to a lookalike Injective public infrastructure endpoint. The attacker gained access via a legitimate maintainer's GitHub account, published the malicious version, and simultaneously pushed version 1.20.21 to 17 other @injectivelabs-scoped packages pinned to the compromised SDK, amplifying blast radius to transitive dependents. The compromise was detected and reverted within roughly an hour by the account owner, but the malicious release artifacts remained downloadable on npm and GitHub at time of writing.

TL;DR A hijacked maintainer account published a backdoored @injectivelabs/sdk-ts npm release that silently exfiltrates crypto wallet private keys and mnemonics, spreading via 17 dependent packages pinned to the malicious version.
Document

What to do

The summary tells you the compromise happened and was reverted, but not the fix version or the remediation steps. The clean release is @injectivelabs/sdk-ts@1.20.23. Socket's stated actions:

  • Audit package.json for any @injectivelabs-scoped package not pinned to a specific version that could resolve to 1.20.21; move it to 1.20.23.
  • Treat any private key or mnemonic that passed through these packages as compromised — move funds and rotate keys/mnemonics.
  • Audit transitive dependencies, not just direct ones: the attacker deliberately pushed 1.20.21 of 17 packages that pin the malicious SDK, so a direct-dependency audit is insufficient.

Note the malicious version is only deprecated on npm, not removed, and the GitHub release artifacts are still live — so a naive install can still pull it.

How it works (detection detail the summary omits)

The stealer does not fire at install time; it triggers during normal library use, which is why an npm install audit alone won't surface it. The malicious code lives in:

  • /dist/esm/accounts-jQ1GSgaW.js
  • /dist/cjs/accounts-Cy0p4lLW.cjs

fromMnemonic and fromHex are hooked with trackKeyDerivation(marker, secret), where marker (e.g. "fm") records the derivation method and secret is the full mnemonic or private-key material. Records are base64-encoded and POSTed to a char-obfuscated endpoint on Injective's own-looking infrastructure: https://testnet.archival.chain.grpc-web.injective.network. The point of that hostname is traffic blending — exfiltration hides inside normal InjectiveLabs network traffic, so egress filtering on unknown domains won't catch it.

Indicators of compromise

File SHA-256 hashes for the infostealer artifact:

  • 103c4e6181151c1bcfedc41506cd1815458c38375d08a8fcd9981dbe0b965ce0 — accounts-Cy0p4lLW.cjs
  • 9a59eb454f3ca3fe91214136ee5edd417cc47a80e6f169b52099d6561944baf9 — accounts-jQ1GSgaW.js

Timeline (all GMT+2, 2026-06-08): test-backdoor-check branch created 20:06 → malicious 1.20.21 published 22:59 → revert commit 23:18 → clean version published 23:48.

Organisations named here

  • Injective Labs
  • trackKeyDerivation

Technologies named here

  • Socket
  • @injectivelabs/sdk-ts
  • @injectivelabs scoped packages
  • npm
  • TypeScript

Techniques named here

  • Supply chain compromise via compromised developer account
  • Hooked function credential/key theft
  • Delayed/deferred execution to evade detection
  • Data exfiltration via base64 encoding over HTTPS POST
  • Blending malicious traffic with legitimate infrastructure
  • Transitive dependency poisoning

Threat actors named here

  • Unnamed threat actor