NPM Supply Chain Attacks: How Hackers Stole Millions from Crypto Wallets

Happy New Year, anon! 🎉

Hope you made it through the holidays without getting drained, both mentally and cryptographically. While most of us were enjoying time off, attackers decided Christmas Day was the perfect time to backdoor Trust Wallet and steal $6 million. Classic.

2025 was... a lot. We watched prediction markets prove everyone wrong (again), AI agents started trading on-chain (what could go wrong?), and somehow the industry still can’t figure out that “admin keys in a hot wallet” is a bad idea. On the bright side, we’re seeing real maturity in security practices, more bug bounties, better incident response, and projects actually taking audits seriously before launch instead of after the exploit.

But here’s what kept me up at night this year: supply chain attacks. Not the flashy smart contract hacks that make headlines, but the quiet, patient compromises lurking in your node_modules folder. The kind where you run npm install and unknowingly invite an attacker into your build pipeline.

September’s “Qix” attack compromised packages with 2 billion weekly downloads. Let that sink in. Two. Billion. And the malicious code was only live for two hours before detection. That’s how fast things move now.

So for the first newsletter of 2026, I wanted to do a proper retrospective, seven years of supply chain attacks targeting crypto, from the 2018 event-stream incident that wrote the playbook, to the React2Shell chaos that closed out December.

More importantly, I’ll break down the defenses that actually work.

Grab your coffee. Let’s get into it.

Coinspect’s Wallet Security Ranking is an objective, transparent, and regularly updated evaluation of leading cryptocurrency wallets. It focuses on critical security features like anti-phishing defenses, transaction clarity, and protection against blind signing, helping users choose wallets that prioritize their safety.

Link: https://www.coinspect.com/wallets/

The crypto ecosystem has become ground zero for supply chain attacks.

These incidents share common patterns: social engineering, trust exploitation, and the weaponization of the npm dependency graph.

For organizations building in Web3, understanding these attack vectors and implementing robust defenses isn’t optional, it’s existential.

For supply chain security assessments, SBOM/QBOM generation, and dependency audits for your Web3 project, reach out to @__Raiders.

1. November 2018: The event-stream Attack (The Blueprint)

The attack that defined modern supply chain threats. An attacker using the pseudonym “right9control” socially engineered their way into maintaining the popular event-stream package (~2 million weekly downloads). They introduced a malicious dependency called flatmap-stream containing obfuscated code that specifically targeted the Copay Bitcoin wallet.

The payload used AES-256 encryption with the target package’s description as the decryption key - meaning it only activated when running within Copay’s build environment. The malicious code remained undetected for over two months before a curious developer noticed unusual behavior. This attack established the playbook: gain maintainer trust, inject targeted malware, and exploit the transitive dependency chain.

2. December 2023: Ledger Connect Kit Compromise

A former Ledger employee fell victim to phishing, allowing attackers to hijack Ledger’s npm account and publish malicious versions (1.1.5, 1.1.6, 1.1.7) of the @ledgerhq/connect-kit library. The injected “Angel Drainer” malware presented fake wallet connection modals, draining over $600,000 from users across DeFi applications including SushiSwap, Zapper, and Revoke.cash within hours.

The attack demonstrated how a single compromised package could cascade across the entire DeFi frontend ecosystem, the connect-kit-loader was a dependency for over 20,000 GitHub repositories.

3. March 2024: XZ Utils Backdoor (CVE-2024-3094)

While not npm-specific, this CVSS 10.0 attack deserves mention for its sophistication. An attacker operating as “Jia Tan” spent nearly three years building trust as a maintainer of the XZ compression utility before inserting a backdoor targeting SSH authentication on Linux systems. Discovered by Microsoft engineer Andres Freund investigating a mere 500ms latency increase, this attack was weeks away from compromising virtually every Linux server globally.

It represents the patient, state-actor-level approach increasingly seen in supply chain attacks.

4. December 2024: @solana/web3.js Compromise

Attackers used spear-phishing to compromise a maintainer’s npm account, injecting credential-stealing code into versions 1.95.6 and 1.95.7 of this widely-used Solana JavaScript SDK (400,000 weekly downloads, 3,000+ dependent projects). The malicious payload exfiltrated private keys through fake CloudFlare headers to an attacker-controlled domain registered weeks earlier.

The attack specifically targeted the addToQueue function to capture wallet private keys during legitimate operations.

5. September 2025: The “Qix” Attack

The largest npm supply chain attack in history. A sophisticated phishing campaign targeting maintainer Josh Junon (”qix”) led to the compromise of 18 popular npm packages including chalk, debug, and ansi-styles—collectively seeing over 2.6 billion weekly downloads.

The injected code operated as a browser-based interceptor, hooking fetch, XMLHttpRequest, and wallet APIs (window.ethereum, Solana APIs) to silently redirect cryptocurrency transactions using Levenshtein “nearest match” algorithms to generate visually similar attacker addresses.

The malicious versions were live for approximately 2 hours before community detection, but the blast radius was enormous, any fresh install or lockfile update during that window was compromised.

6. December 2025: Trust Wallet Browser Extension Backdoor

On Christmas Day, it was found that the version 2.68 of the Trust Wallet browser extension contained malicious code exfiltrating encrypted mnemonic phrases to api.metrics-trustwallet.com.

Unlike dependency-based attacks, this was direct modification of the extension’s source code within their analytics logic, the attacker leveraged PostHog (a legitimate analytics library) as the exfiltration channel. Losses exceeded $6 million across Bitcoin, Ethereum, and Solana networks.

The domain registration (December 8) and first request timestamps (December 21) suggest the attacker had access to developer systems or deployment pipelines for weeks before activation.

This represents APT-level persistence.

7. December 2025: React2Shell (CVE-2025-55182)

Closing out 2025, a CVSS 10.0 vulnerability in React Server Components enabled unauthenticated remote code execution via insecure deserialization in the RSC “Flight” protocol. While not a malicious package injection, it highlights how vulnerabilities in foundational libraries can create catastrophic exposure.

Default Next.js applications created with create-next-app were immediately exploitable.

With React powering ~40% of developer projects and Next.js serving as the leading React framework, over 968,000 vulnerable instances were identified. Post-exploitation activity included cryptocurrency mining, credential harvesting from cloud metadata services, and deployment of Cobalt Strike beacons.

These attacks map directly to the supply chain compromise techniques documented in the MITRE AADAPT framework (ADT1195) and its sub-technique covering Supply-Chain Attacks Targeting Digital Asset Infrastructure (ADT1195.001).

The JavaScript supply chain presents unique risks for crypto applications. NPM packages execute across multiple contexts and each offers different attack surfaces:

1. Development environments: Lifecycle hooks (postinstall, prepare, prepublishOnly) execute arbitrary code during installation. The September 2025 attack could have been far worse if it had targeted these hooks rather than browser runtime.

2. CI/CD pipelines: Compromised dependencies can inject malicious code into production builds. Without frozen lockfiles, automated deployments become attack vectors.

3. Browser runtime: Frontend dependencies have direct access to wallet APIs and can intercept transactions. The Qix attack specifically targeted window.ethereum and Solana wallet APIs, operating at the JavaScript execution layer where traditional security tools are blind.

4. Transitive dependencies: The real danger lies in the dependency graph. A package like debug or chalk appears in thousands of dependency trees. Compromising one high-value transitive dependency provides access to countless downstream applications without directly targeting them.

For supply chain security assessments, SBOM/QBOM generation, and dependency audits for your Web3 project, reach out to @__Raiders.

The most effective defense starts with strict dependency management. Here’s the essential configuration:

Always commit lockfiles:

• package-lock.json (npm)

• yarn.lock (Yarn)

• pnpm-lock.yaml (pnpm)

Lockfiles record exact versions of your entire dependency tree, including transitive dependencies. During the Qix attack, projects with strict lockfiles could quickly identify exposure and roll back those without had to manually audit entire dependency trees.

Use strict install commands:

# In CI/CD - ALWAYS use frozen lockfile commands

npm ci   # npm (removes node_modules, installs from lockfile)

yarn install --frozen-lockfile   # Yarn v1

yarn install --immutable         # Yarn v2+

pnpm install --frozen-lockfile   # pnpm

Never use npm install in CI/CD, it can update the lockfile and introduce unreviewed dependency changes.

Pin exact versions in package.json: Add to your .npmrc:

save-exact=true

This prevents semver ranges (^ or ~) from allowing automatic updates to newer, potentially compromised versions.

Disable lifecycle scripts by default:

# In .npmrc

ignore-scripts=true

Many attacks abuse postinstall hooks. pnpm disables these by default in CI environments.

Implement minimum release age (pnpm v10.16+):

# In .npmrc or pnpm configuration

minimumReleaseAge: 3d  # or more conservative: 60d

This enforces a cooldown period before newly published versions become eligible for installation. The Qix attack’s malicious versions were live for only 2 hours, a 24-72 hour delay would have prevented most exposure.

To learn more, check out Supply-Chain Guardrails for npm, pnpm, and Yarn by Coinspect team.

1. Software Bill of Materials (SBOM): Generate and maintain SBOMs for every release. When compromises are disclosed, SBOMs enable rapid identification of affected builds across your entire deployment history. Consider formats like CycloneDX or SPDX for interoperability.

2. Quality Bill of Materials (QBOM): Beyond just listing components, track the provenance, security posture, and maintenance status of dependencies. This is essential for understanding true supply chain risk.

3. Private registry mirrors: Organizations handling significant crypto assets should host private npm mirrors with allowlists and malware screening. This creates an air gap between the public registry and your build systems.

4. Runtime monitoring: For Web3 applications, implement monitoring for unexpected wallet API hooks or address rewrites. Content Security Policy (CSP) can constrain script behavior in browsers, though sophisticated attacks like the Qix malware were designed to evade detection.

5. Automated scanning with context: Tools like npm audit, Dependabot, Renovate, and commercial SCA solutions identify known vulnerabilities. However, don’t blindly auto-merge updates, the September 2025 attack compromised legitimate packages, not typosquats. Combine automated scanning with differential analysis to detect unexpected code changes between versions.

6. Package provenance verification: npm now supports provenance statements allowing public attestation about where, when, and by whom a package was built. Verify provenance for critical dependencies before updating.

For supply chain security assessments, SBOM/QBOM generation, and dependency audits for your Web3 project, reach out to @__Raiders.

1. Lockfiles are non-negotiable: They’re your primary defense against dependency drift and the first line of investigation during incidents.

2. Never use npm install in CI/CD: Always use strict install commands that respect lockfiles and fail on drift.

3. Treat lifecycle scripts as untrusted code: Disable by default, enable explicitly when required and reviewed.

4. Delay adoption of new releases: A 24-72 hour wait (or longer via minimumReleaseAge) provides a safety buffer for community detection.

5. Internal code is also a target: The Trust Wallet incident shows attackers may compromise internal systems, not just external dependencies. Implement code signing, require multi-party approval for releases, and monitor deployment pipelines.

6. Maintain comprehensive BOMs: SBOMs, QBOMs, and dependency inventories enable rapid response when (not if) the next supply chain attack is disclosed.

Supply chain security requires defense in depth.

No single control prevents all attacks, but layered defenses, strict pinning, lockfiles, script controls, delayed adoption, provenance verification, and continuous monitoring - significantly reduce your attack surface and enable rapid response.

For supply chain security assessments, SBOM/QBOM generation, and dependency audits for your Web3 project, reach out to @__Raiders.