Malicious npm dependency poisoning exposes crypto wallet credentials

At a glance

What this is: A malicious npm package update turned a trusted SDK dependency into a crypto-stealing payload that could reach 87 downstream packages and more than 112,000 downloads.

Why it matters: It matters to IAM, PAM, and NHI teams because supply chain trust now directly affects secret handling, code provenance, and the protection of credentials embedded in developer and wallet workflows.

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.

👉 Read OXSecurity's analysis of the Injectivelabs/sdk-ts npm supply chain compromise

Context

Dependency compromise is a governance problem before it is a malware problem. When a package registry becomes the delivery path, teams inherit risk from the trust they place in versioning, maintainers, and downstream transitive dependencies. For identity and secrets programmes, that means the boundary between application supply chain security and credential protection is much thinner than many controls assume.

This incident is especially relevant where developers, wallets, tokens, and mnemonic phrases intersect. The malicious code targeted wallet-handling logic rather than the main application, which shows how attackers increasingly abuse trusted software components to reach secret material without having to break perimeter controls first.

Key questions

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. That breaks the assumption that the build pipeline only consumes trusted software. In practice, pinning, approval workflows, and provenance checks are the controls that stop a compromised package from becoming an application compromise.

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. If a poisoned dependency can read or forward those values, the theft looks like normal program behaviour until the damage is done. That is why secret handling needs code and runtime controls, not just storage controls.

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. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.

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.

Technical breakdown

How malicious dependency updates reach downstream projects

Package poisoning works when a trusted maintainer path is abused to publish a malicious version that still satisfies dependency resolution. If projects are not pinning exact versions, or if transitive dependencies update automatically, the malicious package can flow into builds without an obvious change request. The risk is amplified in ecosystems where many packages depend on a shared SDK, because the compromise inherits legitimate trust and appears operationally normal until the payload executes.

Practical implication: lock dependency versions and require review before any package update can enter build pipelines.

Why wallet and mnemonic handling is a high-value target

Mnemonic phrases are the master recovery material for many crypto wallets, so any code path that reads, transforms, or exports them becomes an immediate theft target. In this case, the malware inserted collection and exfiltration logic directly into wallet-handling routines, meaning the attacker did not need to search broadly for secrets. That pattern resembles secrets theft in application security, where the sensitive object is harvested at the exact point the application legitimately touches it.

Practical implication: isolate secret-handling code paths and treat them as protected zones for extra review and runtime monitoring.

Why targeted supply chain malware evades detection longer

The malware was described as highly targeted, with only collection and sending logic added and secondary packages modified to point to the malicious version. That keeps the code footprint small and reduces the chance that broad heuristics or simple diffing will flag it quickly. This is a familiar supply chain pattern: minimal payload, trusted distribution channel, and indirect propagation through clean-looking dependencies.

Practical implication: add package provenance checks and behavioural scanning, not just signature-based malware detection.

Threat narrative

Attacker objective: The attacker wanted to steal cryptocurrency by capturing wallet recovery material from systems that trusted the poisoned package.

1. Entry occurred through a malicious npm upload of Injectivelabs/[email protected] and dependency tree redirection from related packages to that version.
2. Credential or secret access happened when the payload executed wallet-handling logic and read mnemonic phrases from victim systems.
3. Impact was cryptocurrency exfiltration from affected machines, with propagation limited by how quickly teams pinned or remediated dependencies.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Targeted package malware now behaves like a precision access abuse event. The smaller the payload and the more specific the collection logic, the longer simple malware controls can miss it. That matters because adversaries no longer need broad disruption to succeed, they only need a narrow path to secret material. Teams should align detection, provenance, and secret handling controls around that reality.

Secrets sprawl in developer ecosystems remains the underlying named failure mode. Our research on the State of Secrets in AppSec shows how fragmented secrets practices, slow remediation, and poor developer adherence create an environment where poisoned dependencies can succeed. The operational conclusion is clear: if secret handling is embedded in code paths, the code supply chain becomes part of the identity perimeter.

Runtime trust must be narrower than package trust. Software teams often validate what they download but not what the package can read once executed. This incident shows why secrets governance cannot stop at repository scanning. Practitioners need to assume that any dependency touching wallet, token, or credential logic is a potential exfiltration path.

Attackers are exploiting the gap between application security and identity security. Packages, tokens, mnemonic phrases, and build-time credentials are all identity-adjacent assets. When they are governed separately, the attacker can move through whichever control plane is weakest. Security teams should merge application provenance controls with NHI and secrets governance to reduce that gap.

From our research:

• 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.
• Forward pivot: Read 52 NHI Breaches Analysis for the breach patterns that show how exposed credentials become operational incidents.

What this signals

Secrets governance now has to extend into the software supply chain. When a malicious package can reach wallet handling code, the practical boundary is no longer just secret storage. Teams need to connect dependency controls, runtime monitoring, and identity governance because the same application path can expose both application data and non-human credentials.

Package provenance is becoming a control objective, not a developer convenience. A build that can accept unreviewed dependency changes is also a build that can accept secret theft logic. That means security teams should treat provenance, version integrity, and sensitive function isolation as part of the same control story, especially where code handles mnemonic phrases, tokens, or API keys.

The operational signal is clear: programmes that still separate AppSec, secrets management, and NHI governance will keep missing the path the attacker actually uses. The next control gap is not just whether a secret exists, but whether untrusted code can touch it while looking legitimate.

For practitioners

• 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.
• Scan for registry-to-runtime exfiltration patterns Monitor for packages that make outbound connections after interacting with sensitive objects, especially when the destination domain is unrelated to normal application behaviour.

Key takeaways

• A poisoned npm dependency turned a trusted SDK update into a direct secret-exfiltration path for wallet users.
• The incident reached 87 dependent packages and more than 112,000 downloads, showing how quickly dependency trust can scale risk.
• Pinning, provenance checks, and stricter handling of secret-bearing code paths are the controls most likely to reduce this exposure.

Key terms

• Dependency Poisoning: Dependency poisoning is the abuse of a trusted software package or update channel to deliver malicious code. The attack succeeds because downstream projects accept the package as legitimate, allowing the attacker to reach build and runtime environments through normal development workflows.
• Mnemonic Phrase: A mnemonic phrase is a human-readable recovery string used to reconstruct a crypto wallet or private key. It functions as master secret material, so any software that reads or processes it must be treated as highly sensitive and isolated from unnecessary exposure.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.
• Secret-Handling Code Path: A secret-handling code path is any application logic that reads, stores, transforms, or transmits sensitive credentials such as keys, tokens, or recovery phrases. These paths deserve tighter review and runtime controls because attackers often target them directly after gaining code execution.

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.

👉 The full OXSecurity post covers the malicious version, dependency impact, and technical exfiltration logic.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader security and supply chain risk.