@injectivelabs/sdk-tsnpm
@injectivelabs/sdk-ts is a confirmed malicious npm package (MAL-2026-10165) that steals credentials and exfiltrates sensitive data (malicious version 1.20.21). Do not install it — remove it immediately and rotate any exposed credentials.
Malicious code in @injectivelabs/sdk-ts (npm)
What this malware does
@injectivelabs/[email protected] (published 2026-07-08 ~20:59 UTC) contains a wallet-credential stealer disguised as "key derivation telemetry". A file packages/sdk-ts/src/utils/key-derivation-telemetry.ts plus a hook added to packages/sdk-ts/src/core/accounts/PrivateKey.ts capture wallet secrets during key derivation:
- PrivateKey.fromMnemonic(words) forwards the full BIP-39 mnemonic to trackKeyDerivation('fm', words).
- PrivateKey.fromHex(privateKey) forwards a string-form hex private key to trackKeyDerivation('fh', privateKey) (a Uint8Array input sends the literal 'bytes' instead).
Captured values are queued, base64-encoded, and POSTed on a ~2s batch via fetch() (with a Node https fallback) to an endpoint built at runtime from a String.fromCharCode array, disguised as Content-Type: application/grpc-web+proto with the secret carried in the X-Request-Id header and keepalive:true. Classification: information stealer (mnemonic / private-key exfiltration). Trigger: runtime, on any call to PrivateKey.fromMnemonic() or PrivateKey.fromHex(string) — there is NO install script.
Malicious CODE is present only in @injectivelabs/sdk-ts. The other @injectivelabs/* packages published at 1.20.21 (utils, networks, ts-types, exceptions, and the wallet-* family) were version-bump-only and were deprecated by the maintainer as compromised; they depend on @injectivelabs/[email protected] and therefore deliver the payload transitively. Every affected package now carries the npm deprecation 'SECURITY: version 1.20.21 is compromised. Do not install.'
Introduced in git commits 01219285b16c / fd105db9073a / 5486f13e799d (direct, unsigned pushes to the master branch under a maintainer account). The release was built and published through the repository's GitHub Actions OIDC trusted-publishing workflow (.github/workflows/publish.yaml, event=push, run 28975012939), so 1.20.21 carries a VALID SLSA provenance attestation despite being malicious — provenance attests the build, not the intent. Reverted in commit 7c4b1a092 ('revert: exfiltration telemetry') and fixed in 1.20.23 (1.20.22 was never published). Root cause (how the maintainer account's write access was obtained) is undisclosed by the vendor.
Exfiltration endpoint: the char-code array decodes to https://testnet.archival.chain.grpc-web.injective.network/ , which resolves to an Injective testnet archival node (15.235.87.88, OVH; chain-id injective-888, moniker injective-testnet-archival) — i.e. Injective's OWN infrastructure, NOT attacker-operated infra. Whether the exfiltrated secrets were collectable by the attacker (e.g. via that node's request logs) is unconfirmed. Affected users must assume any mnemonic or private key used with 1.20.21 is compromised and rotate it from a clean machine.
Note: the community report at https://github.com/InjectiveLabs/injective-ts/issues/697 cites the endpoint as 'hexhole.injective.network'; that string does NOT appear in the shipped code and does not resolve. The code-derived endpoint above is authoritative. IoC: [email protected] tarball sha256 5348d2bb381c6abf2592e922920fca51cb9e0cc320c83d6270d83952e821e601.
The wallet/accounts module (dist/esm/accounts-jQ1GSgaW.js) contains injected code that reconstructs a remote host from a char-code array via String.fromCharCode, decoding to testnet.archival.chain.grpc-web.injective.network, and builds the endpoint https://<host>/. When a wallet is created or used, the code reads the BIP-39 mnemonic (via @scure/bip39 generateMnemonic and ethers HDNodeWallet) and POSTs it base64-encoded, placed in an X-Request-Id header with an application/grpc-web+proto content-type, to that endpoint, with a Node http fallback. The char-code obfuscation of the host and the grpc-web framing disguise the exfiltration as normal Injective SDK traffic. Any mnemonic handled by this version is transmitted to the operator of that host, exposing the wallet's master key.
Malicious versions
Indicators of compromise (SHA-256)
Detection & response playbook
Credential / info stealerFind it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @injectivelabs/sdk-ts (version 1.20.21). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @injectivelabs/sdk-ts across your stack and pipelines.
If you installed it — respond
@injectivelabs/sdk-ts is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.
Did it already run?
If @injectivelabs/sdk-ts was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks @injectivelabs/sdk-ts before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.
Frequently asked questions
Campaign
References
Credits
- Amazon Inspector · finder
- r-bedekar · analyst
Detect & block this
O3 blocks @injectivelabs/sdk-ts-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.