How does a malicious npm package steal millions from crypto wallets? The answer lies in a worm-like supply chain attack called Shai-Hulud, which exploited stolen developer credentials to compromise hundreds of packages, demonstrating a fundamental blindspot in the npm ecosystem: the absence of friction when hijacked tokens authorize malicious updates.
The Shai-Hulud campaign represents a paradigm shift in supply chain attacks. Unlike traditional compromises targeting a single package or service, this attack weaponized npm’s token-based authentication to self-replicate across dozens of legitimate projects, stealing secrets from infected developers and using those secrets to compromise further downstream targets. Trust Wallet, a crypto wallet serving 200 million users, became the campaign’s most visible victim when attackers leveraged leaked GitHub developer tokens to inject malicious code directly into a browser extension, resulting in $8.5 million in losses from over 2,500 wallets.
The Evolution of Shai-Hulud: From September to December 2025
The Shai-Hulud campaign emerged in September 2025 when attackers compromised over 180 npm packages using a self-propagating worm that collected developer secrets with TruffleHog, a legitimate credential-scanning tool weaponized for extraction.
By November, the second iteration—Shai-Hulud 2.0—had mutated dramatically. The worm now targeted 800+ npm packages, with attackers uploading over 27,000 malicious packages. These infected packages leaked approximately 400,000 raw secrets across more than 30,000 GitHub repositories, with over 60% of exposed npm tokens remaining valid weeks later.
In December 2025, researchers at Aikido security discovered a third variant embedded in the npm package “@vietmoney/react-big-calendar,” which had been dormant since March 2021. This strain showed significant refinements:
- The initial payload was renamed to “bun_installer.js” with obfuscation applied fresh from source code
- Leaked secrets now went to repositories marked “Goldox-T3chs: Only Happy Girl”
- Secret filenames adopted letter substitution to evade detection (3nvir0nm3nt.json instead of environment.json)
- The “dead man switch” wiper was removed, suggesting attackers valued retention over destruction
Crucially, Aikido researchers detected minimal spread from the December variant, suggesting they caught the attackers testing payload variations before a wider deployment. The code obfuscation patterns indicated the attacker had access to original Shai-Hulud source code, not a copy-cat variation.
Why This Matters: The Real-World Cost of Compromised Tokens
Trust Wallet’s December 24, 2025 incident illustrates the cascade of failures that follow a token compromise. Attackers obtained developer GitHub secrets, gaining API access to Chrome Web Store. They then:
- Modified Trust Wallet’s source code to inject data-stealing JavaScript
- Published version 2.68.0 bypassing internal review processes
- Registered fake analytics domains (metrics-trustwallet.com) to collect sensitive wallet data
- Executed unauthorized transactions from over 2,500 wallets before detection
What makes this attack operationally significant is the removal of friction. A human review would have caught the malicious code. API gating would have required approval. But with a leaked Web Store API key, the attacker achieved automated weaponization.
For defenders, the implications are grim: your npm token today becomes a bridgehead into your GitHub secrets, which unlock your deployment keys, your CI/CD pipelines, and your production source code. Shai-Hulud proved this chain works at scale.
How the Attack Chain Unfolds
Shai-Hulud operates as a self-replicating infection, not a one-time compromise. The mechanism:
Stage 1: Initial Compromise
Attackers compromise a developer’s environment or steal an npm token. They inject malicious code into an npm package and publish it. The code activates during build or install, triggering credential harvesting.
Stage 2: Credential Exfiltration
Using TruffleHog, the worm scans the infected machine for secrets: npm tokens, GitHub PATs (Personal Access Tokens), cloud provider credentials, API keys. These are written to JSON files with obfuscated names.
Stage 3: Self-Replication
Here lies the worm’s power. With a stolen npm token, the malware fetches the top 100 most-downloaded packages published by the compromised developer. It clones them, injects the same malicious payload, and republishes them using the hijacked token. Each new victim repeats the cycle.
Stage 4: Data Exfiltration
Stolen secrets are pushed to attacker-controlled GitHub repositories with carefully chosen repository descriptions (“Sha1-Hulud: The Second Coming,” later “Goldox-T3chs: Only Happy Girl”). These descriptions help the attackers identify their own repositories among thousands.
Stage 5: Downstream Exploitation
With stolen cloud credentials and CI/CD tokens, attackers now have access to downstream targets. Trust Wallet’s incident shows how leaked GitHub developer tokens became the springboard for Chrome Web Store API access and ultimately wallet compromise.
Ecosystem Blind Spots Enabling the Attack
Shai-Hulud’s success reveals three structural weaknesses in the npm ecosystem and developer infrastructure:
1. Tokens as Master Keys Without Expiration or Audit
npm tokens grant full authority to publish new versions, transfer ownership, and access all scoped packages under a developer account. Once compromised, these tokens work indefinitely unless explicitly revoked. Trust Wallet’s incident shows no monitoring detected the unauthorized Web Store API release until wallets were drained.
2. Automated CI/CD Release Chains Bypass Human Review
Modern development automates package publishing through CI/CD pipelines. With an API key, attackers bypass code review, security gates, and manual approval. The attacker’s malicious code looks indistinguishable from a legitimate release to automated systems.
3. GitHub as a Credential Repository
Developer GitHub secrets (stored in Actions, environment variables, or accidentally committed) are the target. Once stolen, these secrets unlock cloud platforms, deployment systems, and external APIs. npm tokens themselves often get stored as GitHub secrets, creating a single point of failure.
These aren’t mistakes by developers. They’re design choices optimizing for speed over friction. But speed becomes liability when a single token gives an attacker control over 100+ packages simultaneously.
What Defenders Should Do Now
For npm users and developers: Audit your GitHub Actions secrets immediately. Use short-lived tokens with minimal scope (publish-only, not account-wide). Enable two-factor authentication on npm. Monitor npm package updates from your dependencies in real-time, not after install.
For organizations with crypto or sensitive assets: Treat developer credentials as identity—not just convenience. Implement credential rotation on a monthly cycle. Block unpublished releases from reaching production without human sign-off, even for automated pipelines. Consider vendor-locking dependencies to specific git commits rather than npm versions to prevent mid-chain mutations.
For npm and package registries: Implement rate-limiting on bulk package publish operations. Flag accounts publishing to >50 packages in a 24-hour window. Require step-up authentication (email confirmation, delay) for API-driven releases of high-risk packages. Segment trust: a token that publishes shouldn’t also have admin rights.
The Shai-Hulud campaign is ongoing. Researchers caught the third variant mid-testing. A fourth wave may already be in development, using the credential cache harvested over the past months. Defense isn’t about stopping the worm—it’s about preventing the cascade that turns a leaked token into drained wallets.