TL;DR: A malicious version of Injectivelabs/[email protected] was uploaded to npm, affecting 87 downstream dependents and 112,378 accumulated downloads while stealing cryptocurrency wallet mnemonic phrases from victim machines, according to OXSecurity. The incident shows how dependency trust and package update workflows can become an identity and secrets exposure channel when build-time controls are weak.
NHIMG editorial — based on content published by OXSecurity: the Injectivelabs/sdk-ts npm supply chain compromise
By the numbers:
- Because this package has 87 downstream dependents, any project utilizing a non-pinned version of the SDK during the window the attack was live automatically pulled the malicious update.
Questions worth separating out
Q: What breaks when dependency updates are not pinned in high-trust applications?
A: When dependency versions are left flexible, a malicious package can enter production through a routine update rather than a visible code change.
Q: Why are wallets, tokens, and mnemonic phrases high-risk secrets in supply chain attacks?
A: They are high-risk because they are often handled in legitimate application logic that an attacker can reuse once code execution is achieved.
Q: How do security teams know if dependency controls are actually working?
A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach.
Practitioner guidance
- Pin critical dependencies and block silent upgrades Require exact version pinning for packages that touch credential, wallet, or secret-handling code, and route any upgrade through explicit review and approval before build promotion.
- Isolate secret-handling code paths Treat mnemonic, token, and key-processing functions as protected modules with heightened code review, dedicated testing, and runtime monitoring for unexpected outbound network activity.
- Add provenance checks to build pipelines Verify package integrity, maintainer history, and release metadata before install, and fail builds when a dependency change alters the trust boundary without a corresponding change ticket.
What's in the full analysis
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- Package-by-package impact list showing which Injective ecosystem dependencies were redirected to the malicious version.
- Malware analysis details including the obfuscated command-and-control destination and the mnemonic-stealing routine.
- Affected version breakdown for teams validating whether their builds or artifacts consumed the poisoned release.
- Recommended remediation steps for updating fixed packages and checking wallet activity after exposure.
👉 Read OXSecurity's analysis of the Injectivelabs/sdk-ts npm supply chain compromise →
npm dependency poisoning: what it means for IAM and secrets teams?
Explore further
Dependency trust has become a secrets governance problem. When malicious code arrives through a package update, the organisation is not only managing software integrity but also the confidentiality of whatever the application can reach. In wallet and secrets-heavy workflows, build trust and secret trust collapse into the same control gap. Practitioners should treat package integrity as part of identity and access governance for software supply chains.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: What should teams do after a secret is found in a public package?
A: They should contain the exposure by revoking or rotating the credential, tracing its downstream permissions, and reviewing every related repository, cloud account, and automation path. The correct response is lifecycle action on the identity, not just removal of the file that contained it.
👉 Read our full editorial: Malicious npm dependency poisoning exposes crypto wallet credentials