Supply Chain Attacks: A Growing Concern for Crypto

The State of Play

Supply-chain attacks went from a rising risk in 2024 to a defining crypto threat vector in 2025. Earlier this year, ReversingLabs documented 23 crypto-focused supply-chain campaigns in 2024, with npm representing 14 of these incidents. Against the backdrop of ~$2.2B in total hacking losses for 2024, the stage was set for this year's dramatic escalation.

The year started with a huge hit, in February 2025, Bybit suffered the largest theft in industry history (Losing ~$1.5B in ETH), driven not by key compromise but by third-party UI tampering (Safe Wallet) in its multisig flow; investigators describe a vendor-chain compromise that altered what operators saw at approval time. In May 2025, an AI-plugin/IDE poisoning wave around Cursor led to ~$500K in direct losses and exposed hundreds of developer machines to backdoors and stealer payloads.

And recently, in September 2025, the JavaScript ecosystem was hit twice: first by a maintainer-phishing event that pushed crypto-drainer code into 18+ core npm packages (e.g., chalk, debug) with total ~2.6B weekly downloads, and days later by a worming campaign (“Shai-Hulud”) that hijacked @ctrl/tinycolor and, via credential theft and CI pivoting, spread to 100–180+ packages.

What are Supply Chain Attacks in Crypto?

A supply-chain attack exploits the trust you place in everyday development tools, the package managers, build systems, wallet SDKs, and IDE extensions that feel as routine as morning coffee. Attackers don't break down your front door; they poison the water supply, inserting malicious code into trusted updates that flow naturally through your normal workflows.

In crypto, this trust sits at the most dangerous intersection: where value meets authorization. Wallet SDKs that construct transactions, signer UIs that display what you're approving, CI pipelines that build your front-end, these aren't just tools, they're the critical path between human decision and digital money.

The pattern repeats with surgical precision: Bybit users thought they were seeing legitimate transaction details when a compromised vendor UI fed them lies. Thousands of npm users received "routine" updates that quietly rewrote recipient addresses or hooked into wallet flows, all delivered through the same trusted channels they used every day. One compromised maintainer account becomes a distribution network reaching across the internet.

The cruelest part? Everything looks normal. Your IDE suggests the update, your build passes, your tests are green. The attack succeeds precisely because it arrives through channels you trust, wearing the clothes of legitimate maintenanc

Humans, Payloads, Worms: The Supply-Chain Path

Attackers don’t hack blockchains, they hack people, then the pipeline. Phish → publish → propagate.

Step 1 - Break the person, Not the system

In the npm wave, core maintainer Qix fell for a 2FA-reset phish threatening account lockdown, giving attackers control within an hour. In the Bybit heist, a Safe{Wallet} developer was socially engineered through stolen AWS tokens and MFA bypass, his compromised workstation opened the door to everything that followed.

Step 2 - Legitimize the payload

With the npm account, attackers pushed "routine" updates to chalk, debug, and 16 other packages that ran install-time credential stealers harvesting developer tokens and cloud access. At Bybit, attackers injected malicious JavaScript into the trusted vendor UI, so signers approved transactions that looked legitimate, but weren't. The same "looks-legit" trick powered Cursor: a fake "Solidity Language" extension from Open VSX executed PowerShell during installation to exfiltrate secrets, leading to ~$500k in wallet thefts.

Step 3 - Amplify and spread.

The npm worm auto-cascaded from 18 initial packages to 187+ compromised releases through stolen maintainer tokens, billions of weekly downloads spreading faster than teams could respond. Shai-Hulud demonstrated the same pattern, worming from @ctrl/tinycolor to 100+ packages in one campaign. Meanwhile, Bybit's attackers rapidly drained $1.5 billion in ETH across multiple addresses once UI approvals were subverted, making it crypto's largest single heist.

The pattern repeats everywhere trust intersects with valuable access: Bybit's compromised vendor UI manipulated transaction displays at the critical moment of user approval. Cursor's ecosystem showed how alternative extension registries can become backdoor distribution networks, turning developer workstations into surveillance posts.

Each attack exploits the same fundamental weakness: humans making trust decisions under time pressure, using tools that look legitimate because they are legitimate, until they're not.

Why this is worse than “Just Phishing”

Phishing scales one victim at a time; supply-chain compromise scales one maintainer → millions of downstream installs in minutes. It abuses transitive trust, so warnings and training aimed at end-users don’t apply, developers install “updates” from known names, CI builds “as usual,” and signers approve transactions in UIs that look correct. Modern campaigns also harvest tokens and secrets at scale, letting attackers leapfrog into orgs’ build systems and vendors, which is why the npm incidents demanded industry-wide emergency triage even where confirmed on-chain thefts remained relatively small.

Defend Your Pipeline: Do This Next

Treat supply-chain risk like hot-path fraud risk: Verify at the moment of authorization and reduce transitive trust. Concretely:

(1) Verify the raw transaction, recipient, amount, calldata, with an independent tool (e.g., Blockscope Transaction Simulator) before signing; don’t rely on a single vendor UI. The Bybit attackers manipulated the trusted Safe{Wallet} interface precisely because users relied on one source of truth. On any signing surface, enforce strict Content Security Policy and Subresource Integrity for third-party JS to prevent tampering.

(2) Pin and verify dependencies; gate publish rights to essential maintainers only; alert immediately on ownership transfers, the npm attack succeeded because Qix's compromised account had broad publishing access. Quarantine post-install scripts by default; they're prime real estate for credential harvesting.

(3) Adopt SLSA (Supply-chain Levels for Software) -style provenance and reproducible, signed builds so consumers can cryptographically verify artifact integrity. This breaks the "looks legitimate" deception that powered all three attacks by creating an auditable chain from source commit to final package.

(4) Short-lived, scoped tokens limit blast radius, the Shai-Hulud worm spread because stolen CI tokens had persistent access. Isolate CI runners to prevent cross-contamination; alert on workflow edits and unexpected publishes. Automation should be predictable, not surprising.

(5) Harden dev machines; Official marketplaces only for extensions (the Cursor attack exploited alternative registries like Open VSX), Workspace Trust enabled to sandbox untrusted projects, and operational signing on hardware wallets with on-device address confirmation, making UI manipulation attacks like Bybit's impossible since the hardware shows the real recipient, not the spoofed one.

The Meta-Lesson

These attacks succeed because they exploit trust at scale. Your defense must verify at scale too, every signature, dependency, and CI run becomes a verification checkpoint rather than a trust assumption.

Written by: Tushar Tiwari, Blockchain Forensics Analyst @ Blockscope

For more information, please reach out to us at [email protected]

Disclaimer: Best Effort Work

This report reflects our best-effort analysis based on information available as of publication. Please note:

• Data limitations: Sources may be incomplete and the dataset can contain inaccuracies, omissions, or errors.

• Subject to change: New or updated evidence may emerge that could materially alter parts of this report.

• Interpretive nature: Findings and conclusions are based on our current understanding and may evolve over time.

• No guarantees: While we’ve taken reasonable steps to ensure accuracy, we cannot guarantee that all information is fully correct or complete.

This document should be treated as a snapshot of knowledge at the time of writing and may be revised if reliable new information becomes available.