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

Key points

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

Somebody broke into a trusted developer's GitHub account and used it to poison a widely used cryptocurrency toolkit. The goal was simple: steal the digital keys that unlock people's crypto wallets.

The target was the Injective SDK, a bundle of code that programmers use to build apps on the Injective blockchain. Think of it as a starter kit for wallets, trading bots and decentralised exchanges.

On June 8, 2025, the attacker pushed a tampered version, 1.20.21, to npm, the huge public library where JavaScript developers download building blocks for their software. They also stamped the same version number on 17 related packages, so anyone updating one would quietly pull in the rest.

The real account holder noticed within minutes, reverted the changes and published a clean release, 1.20.23. But by then the poisoned package had already been downloaded 310 times, as first reported by BleepingComputer.

What did the malicious code actually do?

It waited. The malware only woke up when a developer called SDK functions that create or import a wallet, meaning the exact moment private keys and seed phrases were sitting in memory.

A seed phrase is the string of ordinary words (usually 12 or 24) that acts as the master password to a crypto wallet. Anyone with that phrase can move the money.

Once triggered, the code grabbed the seed phrase and the private key, scrambled them into a format called base64, and quietly shipped them out. Researchers at StepSecurity found the malware collected several keys at once, waited two seconds, then bundled everything into the header of a web request.

Here is the clever bit. The stolen data was sent to a real Injective Labs address on the public internet, so to any monitoring tool it looked like the SDK talking to its own home servers. Old trick, new setting: web attackers have hidden stolen data inside legitimate-looking traffic for years.

Who is at risk?

Anyone who built or updated software using @injectivelabs/sdk-ts between June 8 and the clean release. That includes wallet makers, trading bot developers and DeFi (decentralised finance) app builders.

End users of those apps are only at risk indirectly, if a developer generated production wallets on a machine that had run the tainted code.

Socket also warns that the malicious release was deprecated rather than deleted. The files still sit on GitHub, waiting for a careless build script to pull them down.

What should affected developers do now?

Move the money first. Any wallet whose keys touched a machine running 1.20.21 should be considered burned: transfer the assets to a fresh wallet generated on a clean system.

Then rotate every secret in the development environment, including API tokens, SSH keys and any other credentials that were sitting nearby. Audit build logs for outbound requests to Injective infrastructure that do not match normal SDK behaviour.

This was not a clever new class of attack. It was the same supply-chain playbook that hit event-stream, ua-parser-js and countless others: steal a maintainer's account, ship a bad version, wait for the download counter to tick.

The defence is boring and it works. Lock down the accounts that can publish code, and treat every dependency update as something that needs a second pair of eyes.