Poisoned Injective SDK on npm quietly stole crypto wallet keys for hours

Key points

• Attackers published malicious version 1.20.21 of the @injectivelabs/sdk-ts package on npm on June 8, 2026, detected by researchers at Socket, Ox Security and StepSecurity.
• The poisoned package was downloaded 310 times before the legitimate owner published a clean 1.20.23 release.
• The SDK sees 50,000 weekly downloads and underpins 87 dependent packages with a combined 112,000 downloads.
• Malware stole crypto wallet seed phrases and private keys, disguising the theft as normal Injective Labs traffic.
• The bad release was deprecated rather than removed; malicious files remain reachable on GitHub.

Somebody broke into a trusted contributor's GitHub account and used it to ship a poisoned version of a widely used crypto toolkit. Steal the keys, drain the wallets: that was the whole plan.

The @injectivelabs/sdk-ts package is a TypeScript toolkit developers use to build wallets, trading bots and decentralised exchange apps on the Injective blockchain. On June 8, 2026, the attacker pushed tampered version 1.20.21 to npm, the public library where JavaScript developers pull in building blocks. They pinned the same version across 17 related packages simultaneously, so updating one quietly dragged in the rest.

The legitimate account holder caught the intrusion fast, cut off the attacker's access and published a clean release, 1.20.23. But 310 downloads had already gone out, as first reported by BleepingComputer.

What did the malicious code actually do?

It didn't fire on install. The malware activated only when a developer called SDK functions that generate or import a wallet, precisely the moment private keys and seed phrases were live in memory.

A seed phrase is a string of ordinary words that functions as the master password to a crypto wallet. Anyone holding it can move everything inside. Once triggered, the code grabbed both the seed phrase and the private key, encoded them in base64 and shipped them out. StepSecurity found the malware queued multiple keys for two seconds, then bundled the whole collection into the header of a single web request.

The destination was a real Injective Labs public endpoint, so monitoring tools saw the SDK appearing to call home. Hiding stolen data inside traffic that looks routine is an old technique; this attack just applied it to a new target.

Our July 8 story on fake Paysafe and Skrill SDKs showed a near-identical pattern: attacker uploads plausible packages, waits for developers to install them, collects secrets in the background.

Who is at risk?

Any developer who built or updated software using the package between June 8 and the clean release is a candidate for compromise. End users of finished apps face indirect exposure only if a developer generated production wallets on an affected machine.

Socket warns that the malicious release was deprecated, not deleted. The files still sit on GitHub, reachable by any build script that targets that exact version.

What should affected developers do now?

Move assets first. Any wallet whose keys touched a machine running 1.20.21 should be treated as burned: transfer everything to a fresh wallet generated on a clean system. Then rotate every credential in the development environment, API tokens, SSH keys, the lot. Audit build logs for outbound requests to Injective infrastructure that don't match normal SDK behaviour.

Should you worry about the wider ecosystem?

This wasn't a novel attack class. It's the same supply-chain playbook that has claimed npm packages for years: compromise a maintainer account, push a bad version, watch the counter tick. What makes it sting here is the scale: 87 direct dependents and a cumulative 112,000 downloads across them means the blast radius for any developer who didn't pin versions is hard to map cleanly.

The practical fix is dull and well-established. Enforce multi-factor authentication on every account that can publish to npm, pin dependency versions in production builds and treat any unexpected update as something worth a second look. Npm 12's decision to disable install scripts by default wouldn't have stopped this one, since the malware triggered on function calls rather than install hooks, but it narrows the attack surface for the next attempt.