Injective Labs Supply Chain Hit: Malicious npm SDK Spotted in the Wild
Just saw the breaking news regarding the Injective Labs SDK repository compromise. It looks like a classic supply chain attack where threat actors managed to hijack the GitHub repository to publish a malicious package to the public npm registry.
The specific artifact to watch out for is @injectivelabs/sdk-ts version 1.20.21. According to the report, this version ships with a malicious "telemetry" script that quietly exfiltrates mnemonic seed phrases and private keys to a remote server. If you are working with Web3 or DeFi stacks, you need to audit your dependencies immediately.
You can quickly scan your node_modules directory for the bad version using this bash loop:
find . -path "*/node_modules/@injectivelabs/sdk-ts/package." -exec grep -l '"version": "1.20.21"' {} \;
If that returns any results, nuke the `node_modules` folder and re-install after ensuring the parent package has updated to a safe version.
This is a stark reminder that CI/CD pipelines need strict commit verification. The attackers essentially used the compromised repo access to publish a poisoned build. This isn't just about production runtime; if a developer installs this locally, their personal wallets are gone immediately.
With the rise of these repo hijacks targeting the crypto space, are folks finally starting to adopt SBOMs (Software Bill of Materials) for their internal JS projects, or is it still treated as 'enterprise overhead'?
Solid post. From a SOC perspective, standard EDR often misses this if the script runs inside a node process that looks legitimate. We've started hunting for npm registry anomalies and blocking outbound traffic from build runners to non-whitelisted endpoints.
If you are using Sentinel or a SIEM, you can hunt for suspicious child processes spawning from node.exe that shouldn't be there:
Process
| where ParentProcessName contains "node"
| where ProcessCommandLine contains "http" and NetworkIPAddresses != "::1"
Real telemetry usually goes to analytics domains, not raw IPs.
We've locked our package-lock. files and use strict dependency pinning, but this highlights that even the source of truth can be compromised if the upstream repo is hijacked.
The best mitigation we've found is enforcing signed commits for all published packages. If the commit signature doesn't match the trusted maintainer's key, the CI pipeline fails to publish. It adds some friction for the devs, but it prevents unauthorized package version bumps like 1.20.21 from ever getting to the registry.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access