A tangled ball of colorful wires with a shadowy
Crypto

Injective SDK npm package backdoor targeted private keys and seed phrases

@Injectivelabs/sdk-ts v1.20.21 was downloaded 310 times before removal, and researchers urged key rotation for any exposed wallets.

By AI News Crypto Editorial Team5 min read

A supply-chain compromise hit Injective’s widely used @injectivelabs/sdk-ts npm package, with attackers modifying version 1.20.21 to steal wallet private keys and seed phrases. The malicious release has been removed and deprecated, but researchers warned any secrets handled by affected packages should be treated as compromised.

Key Takeaways

  • A malicious @injectivelabs/sdk-ts release (v1.20.21) was altered to capture private keys and mnemonics by hooking wallet key-derivation functions and sending data out via “fake telemetry.”
  • The SDK’s footprint is large at roughly 50,000 weekly downloads, even though the specific compromised version was pulled after 310 downloads.
  • Exposure risk extends beyond direct installs because v1.20.21 was pinned across 17 other packages in the Injective Labs npm scope.
  • Researchers advised treating any keys or seed phrases passed through affected packages as compromised, while Injective CEO Eric Chen said the issue was fixed and “No funds on the network are at risk,” with affected versions deprecated.

Injective’s npm SDK Backdoor Targeted Wallet Secrets

A software supply-chain attack compromised Injective developer tooling by backdooring the @injectivelabs/sdk-ts npm package. Security researchers at Socket disclosed that version 1.20.21 was modified to steal crypto wallet private keys and seed phrases (mnemonics), a direct hit on wallet security rather than a protocol-level failure.

The malicious code has been removed. Injective CEO Eric Chen said “it’s already fixed, and the affected versions on npm are already deprecated,” and added: “No funds on the network are at risk,” framing the incident as a dependency compromise that could impact developers and users who ran affected builds, not the Injective chain itself.

How v1.20.21 Exfiltrated Keys via “Fake Telemetry”

Socket’s description is blunt: “The malicious release hooks wallet key-derivation functions, records private keys and mnemonics, and exfiltrates them through fake telemetry,” meaning normal wallet creation or derivation flows could silently leak secrets.

The intrusion path matters. Socket tied the modification to a compromised developer GitHub account, with suspicious commits beginning June 8. That creates a clear risk window for anyone who installed or built against the affected dependency during that period.

Exfiltration was designed to blend in. The stolen data was encoded and sent to a web address made to resemble a legitimate Injective network server, consistent with credential theft that aims to avoid breaking apps or triggering immediate alarms.

Blast Radius: 50,000 Weekly Downloads and 17 Pinned Packages

The package’s scale is the operational problem. @injectivelabs/sdk-ts sees around 50,000 weekly downloads, and Socket called that footprint “significant for developers and applications that handle Injective wallet workflows.” The specific malicious release was downloaded 310 times before removal, which suggests limited confirmed distribution of v1.20.21 itself, but not necessarily limited downstream exposure.

The second-order risk is dependency spread. Socket said v1.20.21 was pinned across 17 other packages in the Injective Labs npm scope, “exposing users who may not have installed the SDK directly.” In practice, pinned dependencies can pull a compromised version into builds through transitive installs, widening the set of affected applications beyond teams that knowingly upgraded the SDK.

Remediation is not just “update and move on.” Socket warned: “Any keys or mnemonics passed through affected packages should be treated as compromised,” implying wallet migration and key rotation for any secrets that touched the compromised code. Socket also said the developer whose account was infiltrated detected the compromise quickly, but cautioned “the campaign itself isn’t yet fully contained,” leaving uncertainty around additional affected releases or packages.

Why Supply-Chain Wallet Theft Keeps Showing Up in Crypto

This incident fits a pattern: attackers increasingly target trusted distribution rails like npm and GitHub instead of trying to break chain cryptography. The Security Alliance (SEAL) has warned that “compromised systems are being used to push malicious code directly into a company’s own GitHub repositories, turning a single compromise into a distribution channel for the next one,” and noted malware is getting broader “with cross-platform payloads, including a rise in macOS-specific campaigns, that combine infostealers, RATs (remote access trojans) and backdoor capabilities in a single package.”

The incentive is clear. CertiK reported wallet compromises were the most costly attack vector in H1 2026, with $444 million stolen across 33 incidents.

Follow-through now matters more than the initial disclosure. Traders and DeFi users should look for updates on whether the campaign is fully contained, whether any additional Injective-scope packages were affected beyond @injectivelabs/sdk-ts v1.20.21, and whether any stolen funds are confirmed from keys that passed through impacted builds. On the developer side, the signal is public remediation: deprecation status across the Injective Labs npm scope and whether major projects confirm key rotation or wallet migrations after potential exposure.

Treat This as a Wallet-Risk Event, Not a Chain-Outage Story

I treat this as a wallet-compromise setup with asymmetric downside for anyone who touched the dependency during the intrusion window, not a protocol exploit that should mechanically reprice Injective’s chain risk. Chen’s “No funds on the network are at risk,” is consistent with that framing, but it does not reduce the urgency for developers and power users because the theft target is the secret material that controls wallets.

The threshold that matters is whether downstream drains get attributed to keys derived or handled via the affected packages. If that linkage shows up and remediation remains uneven across Injective dApps, the setup starts to look structural rather than narrative-driven, because it would translate a supply-chain incident into real, repeated wallet losses.

Sources