Supply Chain Attack: Malicious Version of Injective Labs SDK on npm Steals Crypto Wallet Keys

Executive Summary

A significant software supply chain attack has targeted the cryptocurrency development community. On July 9, 2026, a malicious version of the official Injective Labs Software Development Kit (SDK), packaged as @injectivelabs/sdk-ts, was published to the npm registry. Threat actors reportedly compromised the project's GitHub repository, using this access to push the poisoned package. The malware embedded within the SDK is an infostealer specifically crafted to find and exfiltrate cryptocurrency wallet private keys and mnemonic seed phrases from developers' systems. This attack underscores the persistent threat to open-source ecosystems and the high value placed on developer credentials and assets by malicious actors.

Threat Overview

The attack leverages the trust developers place in official software packages from public registries like npm. By compromising a legitimate and widely used package, the attackers can distribute their malware to a large number of downstream targets who unwittingly install the malicious version.

The attack vector was the compromise of the Injective Labs GitHub repository. With control over the source code and publishing credentials, the threat actors were able to inject their malicious code and publish a new version of the @injectivelabs/sdk-ts package. The malware's payload is highly targeted, focusing on stealing secrets that would give the attackers complete control over developers' cryptocurrency assets. This type of attack is particularly dangerous because the malicious code is executed in a trusted development environment, often with elevated privileges.

This incident is not isolated. It follows a pattern of recent supply chain attacks, including the 'Shai-Hulud' malware on PyPI and compromised Laravel Lang packages, indicating a concerted effort by threat actors to exploit the software development lifecycle.

Technical Analysis

The attack is a classic example of a software supply chain compromise.

1. Compromise Software Supply Chain: The attackers gained unauthorized access to the Injective Labs GitHub account or repository. This could have been through stolen credentials, session hijacking, or a compromised developer machine. This aligns with T1195.001 - Compromise Software Development Environment.
2. Push Malicious Code: The attackers injected their crypto-stealing malware into the SDK's codebase.
3. Publish Malicious Package: Using the compromised access, the attackers published the trojanized package to the public npm registry. This is a form of T1195.002 - Compromise Software Supply Chain.
4. Execution and Credential Access: When a developer installs or uses the malicious package, the embedded code executes. It scans the local system for files containing private keys or seed phrases (.env files, wallet backups, etc.) and exfiltrates them to an attacker-controlled server. This corresponds to T1552.001 - Credentials In Files and T1041 - Exfiltration Over C2 Channel.

This attack highlights the critical need for security controls not just in production, but within the development environment itself. A single compromised developer account can lead to a widespread supply chain incident affecting thousands of users.

Impact Assessment

The direct impact is the financial loss for developers whose cryptocurrency wallets are compromised. The stolen private keys and seed phrases grant the attackers irreversible control over the victims' assets. The secondary impact is reputational damage to Injective Labs and a further erosion of trust in the npm ecosystem. For projects and companies that use the compromised SDK, this incident could lead to the compromise of their own systems or customer funds if the stolen developer credentials provided access to production environments. All developers who have used the @injectivelabs/sdk-ts package recently must assume their environments are compromised and take immediate action to rotate keys and transfer assets.

IOCs — Directly from Articles

No specific file hashes, IP addresses, or domains were provided in the source articles.

Cyber Observables — Hunting Hints

Developers and security teams can look for the following signs of compromise:

Detection & Response

1. Dependency Scanning: Use automated tools like npm audit, Snyk, or Mend to scan package.json and package-lock.json for known malicious package versions. This is a form of D3FEND's System File Analysis (D3-SFA).
2. Behavioral Monitoring: In CI/CD environments, monitor the behavior of build processes. An npm install command should not be making outbound network connections to arbitrary endpoints. Sandboxing build steps can help detect and block this behavior.
3. Egress Traffic Filtering: Implement outbound traffic filtering on developer workstations and build servers to block connections to known malicious domains or un-categorized IP addresses. This aligns with D3FEND's Outbound Traffic Filtering (D3-OTF).

Mitigation

1. Dependency Pinning: Use package-lock.json or npm-shrinkwrap.json to lock down the specific, vetted versions of dependencies. This prevents the automatic installation of a newly published malicious version.
2. Scoped Registries: For organizations, host a private, vetted copy of public dependencies in a local registry (e.g., Nexus, Artifactory). This provides a buffer and allows for security scanning before packages are made available to developers. This is a form of D3FEND's Application Configuration Hardening (D3-ACH).
3. MFA for Developer Accounts: Enforce mandatory multi-factor authentication (MFA) on all developer accounts, especially for platforms like GitHub and npm, to prevent account takeovers that lead to these attacks.
4. Secret Management: Developers should never store private keys or seed phrases in plaintext files. Use secure secret management tools like HashiCorp Vault, AWS KMS, or hardware wallets.