Attackers compromised the official GitHub repository of the Injective Labs project and published a malicious version of the SDK package @injectivelabs/[email protected] to the npm registry, designed to steal private keys and mnemonic phrases from cryptocurrency wallets. According to researchers from Socket, OX Security, and StepSecurity, the attack affected a total of 18 packages under the @injectivelabs scope. All developers using these libraries must immediately upgrade to version 1.20.23 and assume that any keys processed via the compromised version have been exposed.
Attack mechanism and technical details
The compromised version 1.20.21 was published on July 8, 2026. As reported by researchers from Socket, the malicious code was introduced into the official repository through commits made from a developer account with an established contribution history in the project. According to StepSecurity, the malicious release was published via the repository’s own trusted OIDC-based publishing pipeline (trusted-publisher), which allowed it to bypass standard control mechanisms.
The backdoor was implemented by modifying legitimate private key generation functions. A function named trackKeyDerivation() was injected into the code and disguised as a mechanism for collecting anonymized telemetry to optimize the SDK. According to the in-code description, the function supposedly “tracked key derivation methods and timing patterns to identify performance bottlenecks.” In reality, it was passed both an identifier of the key generation method and the sensitive material itself — data sufficient for the attacker to fully reconstruct the private key on their side.
A key characteristic of the malware was its deliberate avoidance of npm lifecycle scripts. The code did not execute at package installation time; it only triggered when a developer directly used the library’s functionality. As noted by OX Security, the malicious logic intercepted mnemonic phrases every time a legitimate user created a wallet or invoked functions that read mnemonics.
Exfiltration mechanism
To reduce the number of outbound requests and lower the chance of detection, the malware accumulated intercepted key derivation data in a queue over a two-second window, then sent it in a single HTTPS POST request to an external server. The exfiltration domain was chosen to mimic Injective’s legitimate infrastructure:
- Exfiltration domain: testnet.archival.chain.grpc-web.injective[.]network
Scope of compromise
The attack was not limited to the main SDK package. According to researchers, the attacker published version 1.20.21 for 17 additional packages under the @injectivelabs scope, which depended on the malicious SDK version and hard-pinned it. This created a risk of transitive compromise — developers who did not install the main SDK directly could still receive the malicious code via dependencies. Affected packages:
- @injectivelabs/utils
- @injectivelabs/networks
- @injectivelabs/ts-types
- @injectivelabs/exceptions
- @injectivelabs/wallet-base
- @injectivelabs/wallet-core
- @injectivelabs/wallet-cosmos
- @injectivelabs/wallet-private-key
- @injectivelabs/wallet-evm
- @injectivelabs/wallet-trezor
- @injectivelabs/wallet-cosmostation
- @injectivelabs/wallet-ledger
- @injectivelabs/wallet-wallet-connect
- @injectivelabs/wallet-magic
- @injectivelabs/wallet-strategy
- @injectivelabs/wallet-turnkey
- @injectivelabs/wallet-cosmos-strategy
Version 1.20.21 of the main package was marked as deprecated in the npm registry. However, at the time the research was published, the release artifacts were still available for download on GitHub.
Impact assessment
This incident poses a high level of risk for several reasons. First, the attack targeted the supply chain of a cryptocurrency project, where compromising private keys leads to direct and irreversible financial losses. Second, the use of a trusted publishing pipeline and an account with a legitimate contribution history made detection significantly more difficult. Third, the coverage of 18 packages with transitive dependencies greatly expanded the attack surface.
The highest risk is to developers of decentralized applications built on Injective Protocol, as well as any projects that use the listed packages as dependencies. It is worth noting that, at the time this material was prepared, no formal incident report from Injective Labs or official npm security advisory had been published — the information is based on analysis by independent research teams.
Response recommendations
- Immediately update all @injectivelabs packages to version 1.20.23 or later.
- Check transitive dependencies: audit your project’s dependency tree for any of the 18 compromised packages at version 1.20.21.
- Rotate keys: any private key or mnemonic phrase that was generated or processed through the compromised version must be considered exposed. Move funds to new wallets with freshly generated keys.
- Review network activity: analyze logs for outbound HTTPS connections to the domain testnet.archival.chain.grpc-web.injective[.]network.
- Pin dependency versions using lock files and consider deploying supply chain security monitoring tools such as Socket or StepSecurity to detect anomalous changes in packages.
This incident demonstrates the growing effectiveness of supply chain attacks carried out through compromising trusted publishing pipelines. Developers working with cryptocurrency infrastructure should prioritize checking dependencies for version 1.20.21 of any of the 18 affected @injectivelabs packages, rotate all potentially compromised keys, and transfer funds before attackers can exploit the stolen material.
