Supply Chain Attacks in Web3 — From NPM to Protocol Exploits

TL;DR — The 5 Vectors Draining Web3 Projects

• Malicious package releases hijack wallet transactions (npm 2025: 18 packages, 2B weekly downloads)
• Compromised maintainer accounts poison official libraries (@solana/web3.js, @dydxprotocol/v4-client-js, ~50M monthly downloads)
• Supply chain attacks via package confusion trick build systems into installing malicious packages (theoretical risk in DeFi)
• Phishing attacks via package names exploit typos to deliver crypto-stealers (solana-py, truffle-vscode)
• CI/CD injection injects malicious code during bundling — source code stays clean, final bundle is weaponized

The Reality: Supply Chain Attacks Are DeFi Attacks

• Frontends bundle JavaScript that executes in users' wallets
• Malicious code intercepted wallet calls and modified transaction recipients before signing
• Build pipelines (CI/CD) automatically pull updates from compromised sources
• Attackers specifically target crypto infrastructure

1. Malicious Package Releases: The npm Mass Compromise (Sept 2025)

1[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], and others

• Any frontend bundling these versions served malicious code to users
• Malicious transactions were signed before users detected anything
• Teams had to halt releases, rebuild, and audit dependencies
• The attack disrupted development pipelines across the ecosystem

• Trusted maintainer account — npm users automatically trusted the packages
• Extremely high download volume — these utilities are ubiquitous
• Obfuscation hid malicious code among legitimate functionality

2. Compromised Maintainer Accounts: Official Libraries Poisoned

@solana/web3.js Backdoor (Dec 2024)

• Attackers controlled the legitimate package — no typos needed
• Every automatic updater (Dependabot, npm-check-updates) was at risk
• Blast radius was massive — potentially thousands of dApps affected

• Even official, well-maintained libraries can be weaponized
• Trust must be verified continuously — monitor maintainer activity, enforce 2FA, use hardware keys
• Pin exact versions and review all dependency changes manually for production
• Incident response windows are critical — every hour matters

dYdX Breach: Coordinated Account Takeover (Jan 2026)

3. Supply Chain Attacks via Package Confusion

1. Company uses internal package @company/auth (private registry)
2. Package name leaks via GitHub, config files, or frontend bundles
3. Attacker publishes @company/auth to public npm with higher version number
4. Build system prefers public package → executes attacker code

• Internal package names (@yourprotocol/cli) often exposed in frontend bundles
• CI/CD systems auto-pull latest versions from public registries
• Most teams use pip --extra-index-url (adds public index) instead of --index-url (replaces with private only)
• High-value targets: packages handling transaction signing or wallet management

• Reserve internal packages names in public registries to prevent external publication
• pip: use --index-url (point exclusively to private index, never --extra-index-url)
• npm: separate internal and external registries; don't mix in one virtual repository
• Scan public repositories for leaked internal package names

4. Phishing Attacks via Package Names

1. High-stakes context — Developers working under pressure (token launch, audit deadline)
2. Complex package names — @solana/web3.js, ethers-ts, viem-utils
3. Cross-ecosystem discrepancies — solana (PyPI) vs solana-py (GitHub)
4. Newcomer influx — Many developers unfamiliar with exact package names

• solana (PyPI) vs solana-py (GitHub) — malicious Solana Python API stealing crypto keys (Sonatype report)
• truffle-vscode vs truffle-for-vscode — exfiltrated secrets from wallet developers (Mend.io)
• bip39 variants — targeted BIP39 wallet generators

• Copy-paste package names directly from official documentation
• Always verify: download count, maintainer, publication date, verified publisher badges
• Use scoped packages (@solana/web3.js) — harder to spoof
• Implement pre-install hooks that check packages against known typosquat blocklists
• Include package verification as part of developer onboarding and code review processes

5. CI/CD Injection: The Invisible Threat

• Bundlers/build tools: Webpack, Vite, Rollup, esbuild
• Transpilers: Babel, TypeScript compiler (tsc), SWC
• Minifiers: Terser, UglifyJS
• Build plugins: vite-plugin-web3, webpack plugins, Rollup plugins
• Build scripts: postinstall, prepare, prepublish hooks

1. Source code on GitHub is 100% clean
2. Build process runs compromised tool/plugin
3. Malicious code injected into final dist/bundle.js
4. Deployed frontend serves weaponized bundle
5. Repository audit shows nothing—the attack lives only in artifacts

• Generate signed transactions
• Call window.ethereum.request()
• Construct calldata for swaps/approvals
• Set allowance amounts

• Replace recipient addresses
• Change allowance from router to attacker
• Increase amounts (type(uint256).max)
• Swap legitimate calldata for drain functions

1// Original in source:
2ethers.sendTransaction({ to: router, value: amount });
3
4// Malicious plugin transforms it to:
5ethers.sendTransaction({ to: attacker, value: type(uint256).max });

• ua-parser-js — backdoor inserted during publish pipeline
• SolarWinds — build system compromise injected malicious code into signed updates

• Smart contracts ✓
• npm packages ✓
• Wallet phishing ✓

• Reproducible builds: git clone → npm ci → npm build must produce identical hashes across machines
• Artifact verification: Deploy only if hash(bundle) == expected_hash (store hash in CI, verify before release)
• Signed releases: Use Sigstore/Cosign/GPG to sign final bundles; verify signatures in deployment pipeline
• No dynamic scripts: Avoid postinstall, prepare, prepublish hooks in production packages
• Immutable CI runners: Use ephemeral, freshly-provisioned runners for builds; never reuse compromised runners
• Build provenance: Record build environment (dependencies, tool versions, commands) for forensic reproducibility

Conclusion: Your Build Pipeline Is Part of Your Attack Surface

• 18 npm packages weaponized in 2 hours (2B weekly downloads)
• @solana/web3.js — ~50M monthly downloads, 3,000+ dependents, private key theft
• dYdX compromised via account takeover — publishing credentials stolen
• 14 of 23 crypto supply chain attacks in 2024 targeted npm (The Hacker News)
• Build pipeline compromise — source code clean, final bundle weaponized

Checklist: Secure Your Supply Chain Now

1grep -E "debug|chalk|ansi|@solana/web3.js" package-lock.json

• Pin exact versions — Remove floating versions (^, ~) from package.json. Use exact versions in lockfiles.
• Scan for unknown packages — Review package-lock.json / yarn.lock for packages you don't recognize.
• Audit for internal name leakage — Search GitHub repos and frontend bundles for internal package names that might be public.
• Verify critical dependencies — Ensure @solana/web3.js, ethers, wagmi, viem are on non-compromised versions.
• Enable Subresource Integrity (SRI) — Add integrity hashes to CDN-served JavaScript bundles.
• Block dependency auto-updates — Configure CI/CD to require manual approval for production dependency updates.
• Use a private registry — Verdaccio, Nexus, or Artifactory with blocklists and allowlists.
• Clear caches after incidents — npm cache clean --force on all dev machines and CI runners.
• Configure package managers correctly — --index-url for pip (never --extra-index-url); separate registries for npm; no mixing internal/external sources.
• Enforce scoped packages — All internal code must use @yourorg/* naming.
• Monitor maintainer account activity — Set up alerts for publishing events from key maintainer accounts.
• Verify registry configuration — Ensure npm/yarn/pip are configured to use private registries exclusively where applicable.
• Implement reproducible builds — Verify that git clone → npm ci → npm build produces identical bundle hashes across clean environments.
• Artifact verification — Store bundle hash in CI; deploy only if hash matches expected value.
• Sign releases — Use Sigstore/Cosign/GPG to sign final bundles; verify signatures in deployment pipeline.
• Avoid dynamic build scripts — Remove postinstall, prepare, prepublish from production packages.
• Use immutable CI runners — Provision fresh runners for each build; never reuse potentially compromised runners.
• Record build provenance — Log tool versions, dependencies, and commands for forensic reproducibility.

Get in touch

FAQ

Glossary