Injective npm Package Attack Exposes Risk to Wallet Private Keys

7 mins mins

Attackers backdoored the official Injective TypeScript SDK on npm, inserting code into 18 packages that captured wallet private keys and seed phrases during normal key-derivation flows before clean replacements were published roughly 49 minutes later.

Injective npm Package Attack Exposes Risk to Wallet Private Keys

What Happened to the Injective npm Package?

Security firm StepSecurity reported on July 8, 2026 that attackers gained access to a trusted developer account and used it to publish a malicious release of the core Injective SDK package, @injectivelabs/sdk-ts@1.20.21. The compromised version was designed to intercept wallet mnemonics and private keys whenever a wallet was created or loaded through the SDK. For related coverage, see Mirae Asset Approved to Buy 92.06% of Korbit for 133.4B Won.

The backdoor did not stop at a single package. Seventeen additional @injectivelabs packages were published with exact dependencies pinned to the compromised 1.20.21 release, bringing the total number of affected packages to 18. For related coverage, see Ethena Opens Free USDe Mint and Redemption via USDC.

Affected packages

The backdoored Injective npm release chain touched 18 official packages before clean replacements were published.

This is a software supply-chain compromise, not a protocol-level exploit or a token-price event. The attack targeted developers who build wallets, dApps, and trading tools on the Injective blockchain, inserting itself into the build pipeline rather than attacking end users directly. For related coverage, see CryptoQuant: Bitcoin Rebound Is Bear Market Recovery, Not Reversal.

npm package compromises are particularly dangerous in crypto because SDKs routinely handle signing keys. Any application that installed the poisoned version and ran key-derivation logic could have silently forwarded credentials to the attacker before the user ever sent a transaction.

Clean 1.20.23 releases replaced the malicious packages approximately 49 minutes after publication. The official injective-ts GitHub repository now shows v1.20.23 as the latest release.

Why Private Keys and Seed Phrases Were the Main Target

Private keys are the cryptographic credentials that authorize transactions from a wallet. Seed phrases, typically 12 or 24 words, are the human-readable backup from which private keys are derived. Possessing either one grants full, irreversible control over the associated funds.

The malicious code was inserted into the key-derivation flow itself, the exact point where these credentials are generated or restored. That placement meant the malware did not need to break encryption or exploit a protocol vulnerability; it simply read the secrets as they were created.

Both StepSecurity and OX Security identified the exfiltration destination as testnet.archival.chain.grpc-web.injective.network. The malware disguised stolen data as routine Injective gRPC traffic, a technique designed to bypass network monitoring that filters by domain reputation.

Once private keys or seed phrases leave the signing environment, an attacker can drain wallets at any time, even months later. Unlike a phishing link that requires user action, a supply-chain credential theft operates silently inside trusted developer tooling.

Who Could Be Affected by the Compromised Injective Dependency

The primary exposure group is developers and teams that ran npm install or npm update for any @injectivelabs package during the 49-minute window on July 8. Anyone who locked to 1.20.21 specifically, or used a version range that resolved to it, could have pulled the backdoored code.

OX Security independently confirmed that the hijacked SDK had 87 downstream dependent packages with a combined 112,378 downloads. These dependents include third-party libraries and tools that bundle the Injective SDK, meaning developers who never directly installed @injectivelabs/sdk-ts could still be exposed through transitive dependencies.

BleepingComputer reported that the malicious 1.20.21 package was downloaded 310 times before deprecation. The official SDK normally receives about 50,000 weekly npm downloads, so the blast radius was limited by the short exposure window.

End users who interact with Injective through established wallets or front-end applications are not automatically affected. The risk applies specifically to environments where the compromised package version ran key-derivation code, such as local development machines, CI pipelines, or backend signing services.

Immediate Steps to Reduce Exposure and Secure Wallets

Any developer or team that used @injectivelabs packages should audit their package-lock.json or yarn.lock files immediately. If version 1.20.21 appears anywhere in the dependency tree, the environment should be treated as compromised.

Credentials generated or loaded while the malicious package was active must be considered leaked. That means rotating all wallet private keys, generating new seed phrases, and moving funds to freshly created wallets. This step is non-negotiable if the compromised version touched any signing logic. The recent integration of Coinbase’s x402 protocol on Injective underscores how many developer workflows now touch the SDK for payment and fee-handling operations.

CI/CD environments deserve special attention. If automated pipelines ran npm install during the exposure window, any secrets, API keys, or wallet credentials accessible to those pipelines should be rotated. Environment variables used in build processes are particularly vulnerable.

Upgrading to @injectivelabs/sdk-ts@1.20.23 or later removes the malicious code, but upgrading alone does not undo credential theft that already occurred. The upgrade prevents future exfiltration; it does not recover already-stolen keys.

Developers should also review npm audit logs and consider enabling two-factor authentication on npm accounts and pinning exact dependency versions rather than using open ranges. Supply-chain attacks in the crypto ecosystem have become a recurring threat, and broader market FUD around ecosystem security tends to amplify when incidents like this surface.

Market Impact Remained Contained

Despite the severity of the supply-chain compromise, the INJ token showed no significant price disruption. At research time, INJ traded at $4.85 with a 1.77% gain over 24 hours and a market cap of approximately $485 million.

INJ spot price

$4.85

At research time, INJ was up 1.77% over 24 hours, a modest move compared with the severity of the package compromise.

The muted price reaction supports the framing that this was a developer-infrastructure incident rather than a protocol breach. No on-chain exploit drained user funds from Injective smart contracts, and the 49-minute remediation window limited real-world exposure. The broader crypto market sat at a Fear & Greed Index score of 23, indicating Extreme Fear driven by factors unrelated to this specific incident.

FAQ About the Injective npm Package Security Incident

What did the malicious Injective npm package do?

The compromised @injectivelabs/sdk-ts@1.20.21 release contained a backdoor that intercepted wallet mnemonics and private keys during key-derivation operations. It then exfiltrated those credentials to an attacker-controlled endpoint disguised as normal Injective network traffic.

Who is affected by this compromise?

Developers, integrators, and automated systems that installed or updated @injectivelabs packages during the 49-minute window on July 8, 2026 are at risk. End users of established Injective wallets and dApps are not automatically affected unless those applications pulled and executed the compromised dependency.

Are my funds safe if I did not install the package?

If you never installed the compromised version and your wallet application has not bundled it, your private keys were not exposed through this attack vector. Standard Injective protocol usage, staking, and trading through verified front-ends were not impacted by this supply-chain compromise.

What should I do if I installed version 1.20.21?

Upgrade immediately to version 1.20.23 or later. Treat all private keys and seed phrases that were generated or loaded while the malicious version was active as compromised. Create new wallets, transfer funds, and rotate any secrets that were accessible in the affected environment.

Has Injective Labs issued a response?

Clean replacement packages (1.20.23) were published within 49 minutes of the malicious release. As of July 10, 2026, no formal public statement from Injective Labs beyond the remediation release has been reported in the sources reviewed for this article.

Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Cryptocurrency and digital asset markets carry significant risk. Always do your own research before making decisions.