My analytical team has identified a serious security incident related to the popular Injective SDK package for npm. Version 1.20.21 of this package was compromised — the malicious code was designed to intercept seed phrases and private keys of users' wallets.

The root of the problem lies in the compromise of a GitHub account belonging to one of the project's developers. The first suspicious commits were recorded on June 8, 2026. The malicious release replaced standard key derivation functions, saving private data and sending it via fake telemetry to an address disguised as a legitimate Injective server.

Particularly alarming is the fact that the compromised version was also found in 17 other packages within the Injective Labs namespace on npm. This means that even users who did not directly install the SDK but used dependent libraries were at risk.

Scope of the Threat and Team Response

According to our data, the malicious version was downloaded at least 300 times. However, the actual number of affected users may be higher due to the cascading effect through dependencies. Injective CEO Eric Chen confirmed that the issue has been resolved, and the affected versions have been marked as deprecated in the npm registry. He also assured that funds within the Injective network itself are not at risk, and there are currently no confirmed cases of stolen funds.

Nevertheless, I strongly recommend considering any keys and seed phrases that may have been used on systems where this package was installed as compromised. Full containment of the attack has not been completed at the time of publication.

This incident fits into an alarming trend: according to CertiK, wallet compromises became the most costly attack vector in the first half of 2026, causing losses of $444.5 million across 33 incidents. My professional opinion: this case is a stark reminder that even trusted packages in the npm ecosystem can be compromised through supply chain attacks. DeFi developers and users need to implement multi-factor code integrity checks and use isolated environments for handling critical keys, especially in light of the increasing sophistication of dependency-level attacks.