Malicious Injective SDK Package Targets Private Keys and Seed Phrases

MakeCryippreferred on

A malicious version of a software tool used by Injective developers was designed to collect wallet private keys and recovery phrases, raising concerns for applications that handled sensitive wallet information through the affected release. Hackers compromised a software package used by developers building wallets and applications for the Injective blockchain, adding code capable of secretly collecting crypto wallet credentials.

Security firm Socket found the malicious code in version 1.20.21 of @injectivelabs/sdk-ts, a package that helps applications connect with Injective and manage wallet-related functions. The package normally receives about 50,000 downloads a week, although that figure includes all versions and does not represent the number of people affected by the incident.

Socket said the compromised version was downloaded about 310 times. However, a download does not automatically mean that a wallet key was exposed. The dangerous code would have needed to run while an application was handling a private key or recovery phrase. No confirmed number of affected wallets has been released, and there is no public evidence that funds were stolen.

The incident did not involve a breach of the Injective blockchain itself. Instead, attackers targeted a trusted software component used by developers, a method commonly described as a software supply-chain attack.

Malicious code was hidden inside a trusted tool

Developers often rely on ready-made software packages rather than writing every part of an application from scratch. These packages can handle tasks such as connecting to a blockchain, creating wallets and signing transactions. In this case, the malicious code was placed inside an official Injective package and was designed to activate when an application processed sensitive wallet information. Socket said it could capture a private key or mnemonic recovery phrase and attempt to send the data away while disguising the activity as ordinary technical reporting.

A private key gives its holder control over the associated crypto wallet. A recovery phrase can be used to restore the same wallet on another device. Unlike a normal account password, these credentials cannot simply be reset after they are exposed.

Private-key compromises have become one of the most damaging forms of crypto attack because criminals can take direct control of wallets without needing to break the underlying blockchain. A recent security review found that private-key incidents accounted for about 40% of the losses recorded in the dataset it examined. The Injective incident also shows why attackers increasingly target software and platforms that users already trust. A familiar package name, established developer account or recognised application can make malicious activity appear legitimate and reduce the chance that users will question it.

Socket said the unauthorised changes were submitted through the GitHub account of a developer with an established history of contributing to the Injective project. The genuine account owner later detected the activity and reversed the changes. The available report does not identify the attacker or explain how the account was accessed.

Seventeen related packages increased the possible exposure

The wallet-stealing code was located in version 1.20.21 of the main Injective SDK package. However, 17 other packages within the Injective npm collection were released with links to the same affected version. This meant that some developers could have received the compromised software indirectly. An application may have installed one Injective package, while that package automatically brought in the affected SDK behind the scenes.

The incident should therefore not be described as 18 separately infected packages. The available evidence shows that the main SDK contained the malicious functionality, while 17 related packages depended directly or indirectly on that version. Socket said the affected release was marked as deprecated after the compromise was discovered and a clean version was published. At the time of Socket’s report, however, the compromised version had not been completely removed from npm, and related release material remained available through GitHub.

Reports have also differed over the exact date of the incident. Socket’s published timeline refers to June 8, while some secondary reports have placed the activity in July. Because the month has not been independently resolved, the exact date should be attributed to the source rather than stated as an undisputed fact.

Developers and affected wallet users should replace exposed credentials

Developers who used version 1.20.21, either directly or through another Injective package, have been advised to assume that wallet credentials processed by the affected software may have been exposed.

Recommended actions include:

• Checking project files and installation records for version 1.20.21.
• Updating affected Injective packages to a verified clean release.
• Clearing stored package copies and rebuilding applications.
• Creating new private keys and recovery phrases.
• Moving assets away from wallets that used credentials handled by the affected software.
• Reviewing wallet activity for unauthorised transactions.
• Revoking permissions previously granted by potentially exposed wallets.

Updating the package alone may not protect a wallet if its credentials were already copied. Once another party obtains a private key or recovery phrase, the old wallet should no longer be considered secure. Wallet users must also examine the permissions they approve. In a separate case, an attacker stole about $92,000 in Tether Gold after a victim signed a malicious permission request, showing that criminals do not always need to obtain a seed phrase directly to take assets.

Although that case used a different technique, it highlights the same wider problem: crypto security depends not only on the blockchain, but also on the software, approvals and services surrounding a wallet. There is currently no evidence that the Injective blockchain was hacked, that every Injective wallet was placed at risk or that a confirmed amount of cryptocurrency was stolen. The known danger is limited to applications that installed the compromised package and processed wallet credentials through it.