Injective resolves npm package compromise in under an hour with zero user impact

A compromised maintainer account, 18 tainted npm packages, and a payload designed to siphon private keys and mnemonic phrases. That’s what Injective Labs was staring down on July 8, 2026. The good news: the malicious code was live for less than an hour, and by all accounts, nobody lost a dime.

The attack targeted @injectivelabs/sdk-ts, a package that sees roughly 50,000 weekly downloads, making it one of the more widely used tools in the Injective developer ecosystem. The compromised version, 1.20.21, was published through a hijacked GitHub account belonging to a trusted maintainer. It was built to extract wallet credentials and relay them to a fake endpoint cleverly designed to look like Injective’s own infrastructure.

How the attack unfolded

Attackers gained access to a maintainer’s GitHub account and used legitimate GitHub Actions to publish the poisoned update. Security firms Socket, OX Security, and StepSecurity identified the breach, which triggered a rapid response from the Injective team. The malicious version was deprecated, access to the compromised account was revoked, and a clean release, version 1.20.23, was pushed out. Total exposure window: approximately 49 minutes.

The compromised version was downloaded over 300 times before it was pulled. Across the @injectivelabs npm scope, 18 packages were affected, with security researchers flagging 87 downstream dependent packages that could theoretically have been exposed. Despite those numbers, Injective reported no actual user impact.

“No funds on the network are at risk,” Injective CEO Eric Chen said.

Why no users were hit

The sub-hour exposure window is the single biggest factor. The 300-plus downloads represent a tiny fraction of the package’s typical weekly volume of 50,000. Many of those downloads were likely automated bots, mirror services, or security scanners rather than developers actively integrating the code into live applications.

Suspicious commits tied to the compromise reportedly began as early as June 8, 2026, a full month before the malicious package was published. That gap suggests either a slow-burn reconnaissance phase or early attempts that didn’t trigger automated alerts.

What this means for crypto developers and investors

For developers building on Injective or any other chain, the practical takeaway is straightforward: pin your dependencies, use lockfiles, enable two-factor authentication on every account that touches your publishing pipeline, and monitor repository commits with the same vigilance you’d apply to your production servers.

Disclosure: This article was edited by Editorial Team. For more information on how we create and review content, see our Editorial Policy.