Injective Labs’ GitHub repository for its TypeScript SDK was compromised and used to publish a malicious npm release that harvests cryptocurrency wallet private keys and mnemonic seed phrases directly from developer applications. Application security firms Socket, Ox Security, and StepSecurity independently flagged version 1.20.21 of @injectivelabs/sdk-ts on July 8, 2026.

What Happened

@injectivelabs/sdk-ts is the official TypeScript/JavaScript SDK for building on the Injective blockchain — a Layer-1 chain used for DeFi, tokenized assets, and decentralized exchanges — and pulls roughly 50,000 weekly downloads. The attacker gained write access to the project’s GitHub repository and pushed the malicious code through the normal release pipeline, so the compromised version carried valid provenance signals and looked like a routine release rather than an obviously forged package.

The same actor also published version 1.20.21 across 17 additional @injectivelabs-scoped packages that depend on and pin the malicious SDK version, so any project pulling in one of those companion packages inherited the backdoored code transitively — even without installing sdk-ts directly.

Technical Details

Unlike most npm supply-chain malware, this payload does not fire on npm install via a preinstall/postinstall hook. Instead, it activates lazily, only when the host application actually calls the SDK’s wallet key-derivation functions — fromMnemonic and fromHex, the standard entry points for importing or generating a wallet key in normal SDK usage.

The malicious code lives in /dist/esm/accounts-jQ1GSgaW.js and /dist/cjs/accounts-Cy0p4lLW.cjs. Both functions are hooked with a call to an added trackKeyDerivation routine that captures the full mnemonic seed phrase and derived private key, base64-encodes the material, and queues it. Rather than sending each capture immediately, the code batches multiple key derivations over a two-second window and ships them as a single beacon — reducing the number of distinct network requests an endpoint monitor or IDS would see.

The exfiltration destination is the most notable evasion technique here: the queued, base64-encoded payload is sent via HTTPS POST to testnet.archival.chain.grpc-web.injective[.]network — a hostname patterned to look like legitimate Injective chain infrastructure (an archival gRPC-web node), rather than an obviously unrelated C2 domain. A developer or automated monitoring system inspecting outbound traffic from an Injective-integrated application would have every reason to assume that traffic to an injective.network subdomain is benign first-party telemetry.

Impact

Because the trigger is key derivation rather than installation, every application, wallet, trading bot, or DeFi front-end that imported the compromised SDK version and generated or imported a wallet key during the exposure window had its mnemonic and private key exfiltrated in plaintext (base64 is encoding, not encryption). A stolen mnemonic or private key gives an attacker complete, irrevocable control of the associated wallet — there is no password reset or session revocation path once a seed phrase is exposed; the only remedy is moving funds to a new wallet before the attacker does.

The malicious version was downloaded 310 times before npm deprecated it, and downstream exposure extends to the 17 dependent packages published at the same version. Given Injective SDK’s use in wallets, trading bots, DEX front-ends, and payment tooling, actual exploitation could include developers testing key-generation flows locally, CI pipelines that exercise wallet creation for integration tests, and — worst case — production services that derive keys at runtime.

Mitigation

  • Check package-lock.json/yarn.lock/pnpm-lock.yaml for @injectivelabs/sdk-ts at version 1.20.21, and for any of the 17 dependent @injectivelabs-scoped packages pinned to that release. Remove or downgrade immediately.
  • Treat any mnemonic or private key that was generated, imported, or derived via fromMnemonic/fromHex while running the compromised version as fully compromised. Move funds to a newly generated wallet on a clean SDK version — do not reuse the key.
  • Block or alert on outbound traffic to testnet.archival.chain.grpc-web.injective[.]network in CI, staging, and production egress monitoring.
  • Audit CI logs and build artifacts for evidence of key-derivation calls during the exposure window (published July 8, 2026 through deprecation).
  • Pin dependencies to known-clean versions and verify publisher/commit provenance on SDK updates rather than trusting scoped-package version bumps automatically.
  • Use a supply-chain scanning tool (Socket, Ox Security, StepSecurity, or equivalent) in CI to catch behaviorally anomalous releases — this campaign was caught by exactly that kind of runtime/behavioral detection rather than static signature matching.

Sources