Injective SDK npm Attack: @injectivelabs/sdk-ts 1.20.21 Stole Wallet Keys Through a Fake Telemetry Function

@injectivelabs/sdk-ts version 1.20.21, published to npm on June 8, 2026 and disclosed by Socket's research team on July 9, 2026, is a malicious release of the official Injective Labs TypeScript SDK that exfiltrates wallet private keys and mnemonic phrases through a disguised telemetry function. The compromised version hooked the SDK's wallet-generation code, so any application that derived a wallet while running it had that wallet's secret material sent to an attacker-controlled endpoint. No CVE has been assigned to this incident as of publication; it is tracked as a malicious npm package release.

This post covers what happened, how the payload executed, every affected package and version, the indicators of compromise, and the first-hour response steps for any team with @injectivelabs/sdk-ts or another @injectivelabs-scoped package in its dependency tree

Attack Summary

• Affected package: @injectivelabs/sdk-ts
• Malicious version: 1.20.21
• Clean version: 1.20.23
• Ecosystem: npm
• Vulnerability class: wallet private key and mnemonic theft via a disguised telemetry function

• Weekly downloads: approximately 50,000

• Dependent packages: 87

• Malicious version downloads: 310

• Disclosed by: Socket Security, July 9, 2026

• CVE: none assigned as of publication

‍

Background

@injectivelabs/sdk-ts is the official TypeScript SDK for Injective Labs Cosmos-based Layer-1 chain. It is the standard library node services, exchanges, and wallets use to derive addresses, build transactions, and query the chain, which is why a compromise in its wallet-generation path has outsized reach across the Injective ecosystem. The package sits in the dependency tree of dozens of downstream Injective tooling packages, so teams can be exposed even when they never installed it directly.

How the Attack Unfolded

The malicious release did not begin as a fresh publish. It came from a legitimate-looking commit history that was reverted and then quietly followed by a second, clean-looking release, a pattern designed to look like a routine version bump rather than a supply-chain compromise.

• June 8, 2026, 20:06 UTC: A new branch is created in the sdk-ts repository
• June 8, 2026, 22:59 UTC: sdk-ts 1.20.21 is published to npm containing the malicious wallet-generation hook
• June 8, 2026, 23:18 UTC: A revert commit is pushed, but the malicious package version remains live on npm
• June 8, 2026, 23:48 UTC: A clean version, sdk-ts 1.20.22, is republished, but the compromised 1.20.21 tarball is not removed from the registry
• At the time of writing, the malicious sdk-ts 1.20.21 artifacts remain downloadable from npm.

Payload Location and Trigger

The infostealer code does not run at install time. The payload ships inside two build artifacts, /dist/esm/accounts-jQ1GSgaW.js and /dist/cjs/accounts-Cy0p4lLW.cjs, and only fires when a consuming application calls the SDK's fromMnemonic or fromHex functions, the standard entry points for deriving a wallet from a mnemonic phrase or a raw hex key. Both functions are hooked with a call to an added function named trackKeyDerivation.

Credential Harvesting

trackKeyDerivation logs a hardcoded marker for which method was used, plus the actual sensitive input behind it: the full seed phrase for fromMnemonic calls, or the raw private-key material for fromHex calls. This is direct capture of the exact secret needed to reconstruct a wallet, not incidental metadata.

Exfiltration

The captured data is base64-encoded and sent via an HTTP POST request to a character-obfuscated endpoint styled to resemble legitimate Injective infrastructure: https://testnet[.]archival[.]chain[.]grpc-web[.]injective[.]network. Routing exfiltration through a domain that mimics InjectiveLabs' own infrastructure blends the malicious traffic with normal SDK usage, which is a deliberate evasion choice rather than an accident of implementation. Once received, the stolen mnemonic or key material is sufficient on its own for an attacker to regenerate the private key and take control of the wallet.

What Is Affected

The blast radius reaches well past teams that installed @injectivelabs/sdk-ts directly. The same actor also published version 1.20.21 across 17 other @injectivelabs-scoped packages that depend on and pin the malicious SDK version, so an application that never lists sdk-ts in its own package.json can still resolve to the compromised code through the dependency tree.

Indicators of Compromise and Behavioral Signals

Treat any environment that resolved @injectivelabs/sdk-ts to 1.20.21, directly or transitively, as compromised, and check for the identifiers below regardless of which of the 18 affected packages was pulled in.

File-system indicators (SHA-256):

Network indicators: outbound POST requests from a Node.js process, backend service, or build environment to testnet.archival.chain.grpc-web.injective.network, when that service has no legitimate reason to talk to Injective testnet infrastructure.

Behavioral indicators: any call into fromMnemonic or fromHex from a version-1.20.21 build of @injectivelabs/sdk-ts should be treated as a credential-exposure event, since the exfiltration happens at the moment of use, not at install.

Immediate Response: The First-Hour Runbook

Prioritize finding where 1.20.21 resolves in the dependency tree, assume any key material that passed through it is burned, and move funds before spending time on forensics.

1. Search package-lock.json, yarn.lock, or pnpm-lock.yaml across every repository for @injectivelabs/sdk-ts and the 17 related packages, checking specifically for version 1.20.21.
2. Resolve the full dependency tree, not just direct dependencies. The attacker pinned 1.20.21 inside dependent packages specifically to catch teams that only audit their own package.json.
3. Pin or upgrade every affected @injectivelabs-scoped dependency to 1.20.23 or later, and avoid unpinned ranges (^, ~, latest) on this scope until confidence in the registry state is restored.
4. Treat any mnemonic phrase or private key ever passed through fromMnemonic or fromHex in an affected build as compromised. Rotate the keys and move funds out of the associated wallets right away.
5. Check outbound network logs for connections to testnet.archival.chain.grpc-web.injective.network from any service, CI runner, or developer machine that built or ran code against the compromised version.
6. Scan build artifacts and lockfile caches for the two SHA-256 hashes above. A hash match confirms the compromised file shipped into a build, even when the version string in package.json looks clean.
7. Purge npm package caches for the @injectivelabs scope in CI/CD before rebuilding, so a stale copy of 1.20.21 is not reintroduced after remediation.

Finding the Package Is Not the Same as Knowing You Were Hit

A dependency scanner that only checks package.json and lockfiles against a known-bad version list can confirm a package is present, but that confirmation cannot show whether the specific vulnerable function inside that package was ever actually called in a running application, and that distinction determined who was genuinely at risk in this incident. The malicious code did not execute on npm install; it waited inside fromMnemonic and fromHex, functions that only run when an application performs one specific action: deriving a wallet.

Two organizations could both have @injectivelabs/[email protected] sitting in their dependency tree. One never calls wallet-derivation functions in that code path at runtime, for example if it only uses the package for read-only chain queries, and its real exposure is close to zero. The other calls fromMnemonic on every user session and had live credential exfiltration for as long as the malicious version was installed. A manifest-based runtime-powered SCA scan still finds every affected package across direct and transitive trees, but confirming whether the vulnerable code actually loaded and executed, reachable versus exploited, is what separates a theoretical finding from a live incident. That confirmation is the layer Kodem's runtime intelligence adds on top of standard SCA, and it is the same layer Kai uses to fold exposure into a single prioritized fix instead of a flat list of affected versions.

Hardening Your Pipeline Against the Next Variant

This incident followed a pattern that repeated across npm, PyPI, and other registries throughout 2026: a trusted maintainer account gets compromised, a malicious version publishes fast, and the attacker weaponizes dependent packages to widen the blast radius. Assume this happens again.

1. Enforce exact version pinning, no ^ or ~ ranges, for any dependency handling cryptographic key material, wallet operations, or secrets.
2. Require maintainer 2FA and publish-token scoping as a baseline expectation when evaluating third-party SDKs that applications will trust with sensitive operations.
3. Monitor outbound network traffic from build and runtime environments for connections to domains that resemble, but don't exactly match, known-good vendor infrastructure.
4. Build runtime visibility into which functions from security-sensitive dependencies, key derivation, signing, secret handling, are actually invoked in each service, so a future compromise of one of those functions surfaces as an anomaly rather than a silent risk. See the open source security approach for how runtime-verified findings replace manifest-only triage.
5. Maintain an internal registry mirror or artifact cache with deprecation and yank enforcement, so a package flagged as compromised upstream can be blocked locally even if the public registry is slow to remove it, as is currently the case with this incident.
6. Build a secrets and key-rotation plan for third-party SDKs before it is needed. The fastest-moving part of this incident was the 19-minute window between malicious publish and revert; response time to rotate exposed credentials should be measured on a similar scale.

What This Incident Signals

Wallet-targeting supply-chain attacks against blockchain SDKs are becoming more deliberate and better disguised, and the technique of hiding exfiltration inside legitimate-looking vendor traffic is likely to spread beyond crypto-focused packages.

• Disguising the exfiltration endpoint as Injective's own testnet infrastructure, rather than an obviously suspicious domain, shows increasing attention to evading both automated and manual traffic review.
• Weaponizing dependent packages to catch transitive users, rather than relying on direct installs alone, is now a repeatable playbook, and defenders should expect it in the next SDK-targeted compromise.
• The narrow window between malicious publish and detection, roughly three hours from the first suspicious commit to the clean republish, suggests maintainer-account monitoring is becoming a meaningful defensive layer on its own, separate from package scanning.

Watch for copycat campaigns against other blockchain and wallet SDKs using the same hook-the-key-derivation-function, exfiltrate-through-vendor-styled-infrastructure pattern in the coming weeks. The technique is now public and reproducible.

Frequently Asked Questions

1. What is the @injectivelabs/sdk-ts npm attack? It is a supply-chain incident where version 1.20.21 of the @injectivelabs/sdk-ts npm package, part of the official Injective Labs SDK, was modified to secretly exfiltrate wallet private keys and mnemonic phrases whenever an application used its key-derivation functions.
2. Which packages and versions are compromised? @injectivelabs/[email protected] contains the actual infostealer code. Seventeen other @injectivelabs-scoped packages were also published at version 1.20.21 with a dependency pinned to the malicious SDK version. The clean version is 1.20.23.
3. How do I know if my environment was affected? Check whether @injectivelabs/sdk-ts or any of the 17 related packages resolved to version 1.20.21 in lockfiles, including as a transitive dependency, and check outbound traffic logs for the exfiltration domain listed above.
4. What credentials does the malware steal? Whatever sensitive material is passed into fromMnemonic or fromHex: full wallet mnemonic phrases or raw private-key material, either of which is sufficient for an attacker to fully reconstruct and control a wallet.
5. Was this assigned a CVE? No. As of publication, Socket's research team tracks this as a malicious npm package incident, not a numbered CVE.
6. Can standard dependency or SCA scanning catch this kind of attack? It can flag that a known-malicious version is present in a manifest or lockfile, but manifest-based scanning alone cannot confirm whether the specific compromised function was ever called at runtime. That distinction requires runtime or reachability analysis layered on top of version detection.
7. What is the fastest way to stop exposure if this package is installed? Pin every @injectivelabs-scoped dependency to 1.20.23 or later immediately, and treat it as a credential-rotation event: rotate any keys or mnemonics that could have touched the affected code path and move funds out of potentially exposed wallets.
8. Where can I track future variants of this kind of attack? Follow Socket's security research blog and the OSSF malicious-packages repository, both of which track newly disclosed npm and PyPI supply-chain incidents as they are confirmed.

The Bottom Line

A 19-minute window between a malicious publish and a maintainer catching it is what kept this incident from being far larger. The next compromised SDK may not get caught that fast, and the packages most likely to carry the damage are the ones sitting quietly in a lockfile, resolved but never directly reviewed. Version pinning and fast patching close the manifest-level gap; runtime visibility into which functions actually execute closes the gap patching alone cannot see.

References

1. Socket Security: Compromised Injective SDK npm Package Exfiltrates Wallet Keys and Mnemonics
2. Kodem Runtime-Powered SCA
3. Kodem Open Source Security Solution
4. From Reachability to Reality: Proving Vulnerable Code Was Executed or Exploited in Production

‍