Malicious npm dependency poisoning exposes crypto wallet credentials

At a glance

What this is: A poisoned npm package propagated through downstream dependents and stole wallet mnemonic phrases from affected machines.

Why it matters: It shows how software supply chain compromise can become an identity and secrets problem when build-time trust is weak and package updates are not tightly governed.

By the numbers:

• The malicious package reached 87 downstream dependents, expanding the exposure surface across the Injective ecosystem.

Context

npm dependency poisoning is the compromise of a trusted package so that downstream developers unknowingly pull malicious code during install or update. In this case, the security gap is not just package integrity, but the way dependency trust can become a channel for credential theft and wallet exfiltration when versions are not pinned and publishing controls are weak.

For IAM and secrets teams, the identity angle is real even though the incident begins in a software supply chain. The attacker abused package trust, likely developer account access, and runtime permission to reach mnemonic phrases, which function like the master key for a wallet. That makes this a governance problem spanning code provenance, account assurance, and secret handling.

Key questions

Q: What breaks when an npm dependency is poisoned before release?

A: The main break point is trust in the package lifecycle. Developers assume the registry version they pull is the maintainer’s intended code, so poisoned dependencies bypass that assumption and can execute during install or runtime. If the package handles secrets, the impact is not just code compromise but credential or wallet theft.

Q: Why do wallet libraries create such high secret-exposure risk?

A: Wallet libraries must handle mnemonic phrases or private keys at the moment of use, which means the secret is eventually present where malware can capture it. That makes these libraries sensitive even when the surrounding application is well controlled, because the exposure happens at runtime rather than only in storage.

Q: How do security teams tell dependency risk from ordinary code quality issues?

A: Dependency risk becomes a security issue when the package can influence secret handling, authentication, signing, or update paths. Ordinary bugs may break functionality, but poisoned packages can turn trusted build inputs into exfiltration channels, especially when version ranges and indirect dependencies are not tightly governed.

Q: What should teams do after a supply chain package has exposed wallet keys?

A: Assume compromise until every affected key path is identified. Revoke or rotate exposed credentials, move assets if they are at risk, and review all systems that resolved the malicious version, including transitive consumers and build artifacts that may have cached it.

Technical breakdown

How a poisoned package reaches downstream projects

A registry poisoning attack works by replacing a legitimate package version with malicious code or by steering dependents to a compromised version. If consuming projects allow semver ranges or unpinned updates, the malicious release can enter build and install paths automatically. The key risk is that dependency resolution trusts the registry and package metadata before any runtime detection occurs. In this article, secondary packages were left clean while their dependency trees pointed to the malicious version, which is a common way to preserve appearance while still delivering payloads.

Practical implication: pin dependency versions and verify package provenance before build systems accept an update.

Why wallet mnemonic theft is a secrets exposure problem

Mnemonic phrases are not ordinary application data. They are the recovery material that controls access to a wallet, so stealing them is operationally equivalent to stealing a credential with full account power. The malware did not need to break cryptography if it could wait until the application legitimately read the phrase in memory or on disk, then exfiltrate it. That is why secret handling must cover runtime access, not just storage controls, especially in packages that handle wallets or signing operations.

Practical implication: treat mnemonic handling as privileged secret processing and minimise where phrases are ever materialised.

How targeted supply chain malware evades basic detection

This campaign was narrow rather than noisy. Instead of spraying obvious malicious behaviour across many packages, the malware focused on collection and transmission logic and used an obfuscated command-and-control endpoint. That makes reputation-based controls and superficial code review less reliable, because the malicious change can look like a small feature addition inside a legitimate wallet library. Supply chain defence therefore has to inspect both the package source and the behaviour it enables after installation, not only signature or popularity signals.

Practical implication: add provenance checks, behavioural review, and dependency monitoring for packages that touch secrets or signing paths.

Threat narrative

Attacker objective: The attacker aimed to capture wallet mnemonic phrases and use them to access cryptocurrency holdings from victim environments.

1. Entry occurred when a malicious version of Injectivelabs/[email protected] was uploaded to the npm registry and made available to downstream consumers.
2. Credential or secret access occurred when the package read wallet mnemonic phrases from victim machines during normal wallet use.
3. Exfiltration occurred when the malware sent the stolen mnemonics to a remote command-and-control server for later misuse.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package trust is now a credential problem: supply chain compromise is no longer just about code integrity, because a poisoned dependency can turn wallet handling into secret theft. When a package reads mnemonic phrases during ordinary application use, the attack surface overlaps directly with secret governance and runtime access control. Practitioners should treat dependency provenance as part of their secrets programme, not as a separate developer concern.

Standing dependency trust creates a hidden exposure window: semver-driven updates and non-pinned packages assume the publisher remains trustworthy between releases, which is exactly the assumption a registry poisoning attack breaks. The failure mode is not simply malicious code, but unreviewed trust transfer from maintainer to consumer and from consumer to runtime. That is why the control gap is lifecycle governance over packages that can touch sensitive material.

Mnemonic phrases are high-value secrets, not ordinary application strings: the article shows why wallet recovery data deserves the same governance discipline as any privileged credential. Once those phrases are materialised in a live client, the protection boundary moves from storage to runtime, and the security question becomes who can cause the application to read them and where they can be sent. This is a clear case for tighter secret handling around wallets and signing workflows.

Developer account compromise amplifies supply chain reach: the article explicitly notes the role of stolen GitHub access tokens, phishing, and account takeover as enabling conditions. That makes publisher authentication and release governance part of the attack surface, not just end-user package hygiene. Teams that rely on third-party libraries should assume upstream account compromise is a realistic source of identity abuse and plan controls accordingly.

Targeted malware in a trusted package is a stronger signal than volume alone: the attack focused on collection logic and hid behind a legitimate wallet ecosystem package rather than broad noisy propagation. That pattern is harder to detect with conventional malware heuristics and easier to miss in review, which means dependency review has to include behaviour-sensitive scrutiny for packages that process secrets. The practical conclusion is to govern package risk by function, not only by download count.

From our research library:

• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: Ultimate Guide to NHIs

What this signals

Dependency poisoning turns software supply chain risk into secret governance risk: the practical lesson for teams is to stop treating package updates as a purely engineering workflow. When packages can reach wallet or credential material, release approval, provenance verification, and secret classification belong in the same control conversation.

Supply chain controls need a secrets-aware boundary: a package that never should have touched mnemonic phrases is the point where software assurance and identity governance intersect. Teams should define which dependency classes can interact with sensitive material and require stronger review for those paths, especially where third parties are involved.

According to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security. That statistic aligns with this incident’s core lesson: third-party trust is already an identity problem, and dependency ecosystems make that exposure harder to see unless governance extends beyond the primary application repository.

For practitioners

• Pin and verify dependency versions Lock critical packages to exact versions, require provenance checks for updates, and block unattended semver expansion in build pipelines that ingest wallet or signing code.
• Treat mnemonic handling as privileged secret processing Classify wallet mnemonic phrases as high-value secrets, minimise where they are read into memory, and isolate any component that must access them.
• Review upstream package publishing controls Require stronger assurance for maintainer accounts, including phishing-resistant authentication and release approval on packages that can reach credential material.
• Monitor for anomalous outbound collection paths Instrument build and runtime telemetry to flag unexpected outbound connections from libraries that should only handle local wallet operations.
• Audit all dependency trees for wallet-adjacent packages Map every indirect package that touches wallets, keys, or signing flows so that a compromise in a secondary dependency does not go unnoticed.

Key takeaways

• A poisoned npm dependency can become a secret-exfiltration channel when it touches wallet or credential material at runtime.
• This incident affected 87 downstream dependents and 112,378 accumulated downloads, showing how quickly registry trust can widen exposure.
• Teams need provenance controls, version pinning, and stricter handling for packages that process mnemonic phrases or other high-value secrets.

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.
• Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
• Command-and-Control Endpoint: The remote server an attacker uses to issue commands, stage payloads, or receive output from a compromised host. In dependency attacks, a stable endpoint can outlast package renames and serve as the most durable indicator of operator reuse.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity controls to the broader security programme they are responsible for.