The Second Major Incident This Year: Understanding NPM Supply Chain Attacks
Since September 8, NPM has not had a truly quiet moment.
The first incident happened in early September. A well-known maintainer, qix, had his account stolen through a phishing email. The attacker used his identity to publish malicious updates to several high-download NPM packages. These packages generated more than two billion weekly downloads, and the injected code silently altered cryptocurrency transactions in the browser.
This week, the second incident surfaced. Security teams reported the Shai-Hulud 2.0 attack, in which the attacker also relied on stolen maintainer accounts to insert malicious installation scripts into hundreds of packages. These scripts were designed to steal local development secrets, tokens, and cloud credentials, to hide inside workflow runners for later use, and to target cloud-hosted CI/CD pipelines in order to collect additional credentials.
Some variants even created malicious GitHub workflows inside affected repositories for future exploitation.
Together, the two incidents raise the same fundamental question:What exactly do NPM supply chain attacks target, and why can a single malicious update create ripple effects across the entire ecosystem?
1. What is an NPM supply chain attack?
The simplest way to understand it is through an analogy.
Imagine a well-known developer on the App Store having their account compromised.
The attacker publishes an update that looks completely normal, and users install it without noticing anything suspicious.
Thousands of devices end up compromised because the update contained hidden malicious code.
NPM works in a similar way.
It is a central registry where developers download reusable modules that provide functions, components, or tools for their projects.
Modern front-end, Node.js, and Web3 applications all rely heavily on these modules.
The shared risk lies here:
Developers generally trust upstream packages and assume that new versions are safe.
Once that trust is abused, the entire dependency chain becomes exposed.
2. What happened in the two major incidents this year?
The qix incident on September 8
The targeted maintainer was Josh Junon, known as qix.
The attack followed a familiar pattern.
The attacker impersonated NPM staff and sent an email claiming that his two-factor authentication was about to expire.
Under pressure, the maintainer submitted the verification code, giving the attacker full access to the account.
Malicious updates were then pushed to several widely used packages.
The injected code focused on browser-based cryptocurrency transactions.
Whenever users initiated an on-chain action through a website, the script intercepted the request and replaced the recipient address with the attacker’s address.
The page still displayed normal data, making the manipulation difficult to detect.
Because the affected packages generated extremely high download volumes, several security reports described this incident as one of the most impactful NPM supply chain attacks to date.
Shai-Hulud 2.0: Expanding from user attacks to developer infrastructure
The first version of Shai-Hulud appeared in mid-September. It used compromised maintainer accounts to inject malicious installation scripts into packages. These scripts executed during package installation and collected secrets from developer machines and CI environments.
Around November 24, security teams confirmed a second, much larger wave known as Shai-Hulud 2.0.
Hundreds of packages were altered with malicious installation scripts.
When developers installed these dependencies, the scripts automatically ran, extracting environment variables, cloud access keys, and CI/CD tokens.
The collected information was uploaded to GitHub repositories controlled by the attackers, often marked with the name “Shai-Hulud.”
Compared with the September attack, which targeted end-user transactions, the new attack attempted to compromise entire development and deployment infrastructures.
This shift made Shai-Hulud 2.0 significantly more dangerous, affecting the foundations of CI/CD automation, cloud workflows, and software delivery pipelines.
3. Why is Web3 especially vulnerable?
NPM incidents affect Web2, SaaS, and CI/CD systems as well.
However, Web3 projects face several additional risks that make the consequences more severe.
Private keys represent real assets
Many teams store deployment keys or management keys in environment variables or CI configurations. Once leaked, these lead to direct financial losses rather than slow, recoverable data exposure.
A compromised front-end directly affects on-chain interactions
An attacker can alter transaction parameters or recipient addresses before the user signs. The interface appears normal, but the signed transaction goes somewhere else.
The Web3 toolchain relies heavily on NPM
Ecosystems such as web3.js, ethers.js, Hardhat, and many related tools rely on NPM modules. Any compromise in the upstream dependency tree quickly spreads into contract development and deployment tools.
In Web2, supply chain attacks often cause outages or data leaks that can be fixed.
In Web3, they can immediately affect keys and blockchain assets, which are irreversible.
4. What do NPM supply chain attacks actually exploit?
They take advantage of three weak points:
Compromised maintainer accounts
Phishing or weak account security allows attackers to publish updates under a trusted identity.
A publishing process that relies on maintainer trust
New versions are accepted without mandatory third-party review or multi-party approval.
Downstream projects that update dependencies by default
Many build pipelines automatically fetch the newest versions, inheriting malicious changes instantly.
The result is not a single vulnerability but an ecosystem-wide assumption that familiar packages and new versions are inherently reliable.
The recent incidents showed that this assumption is dangerous.
5. How OneKey addresses supply chain risks
For attacks that pollute upstream dependencies, the core strategy is to avoid implicit trust in external updates.
Dependency management in the OneKey App
Build systems rely only on locked dependency versions and do not automatically pull newly published updates.
Any dependency upgrade must go through code review and integrity checks.
Critical modules receive additional verification to ensure that their contents match expected behavior.
This prevents accidental adoption of compromised upstream packages.
Hardware wallets isolate users from front-end tampering
Even if a Dapp front-end is affected by a supply chain attack, OneKey hardware wallets verify transactions independently.
Transaction data is parsed inside the secure chip.
The screen displays the actual recipient address, amount, and call details.
Users confirm the transaction based on the hardware wallet’s view rather than what is shown in the browser.
If a front-end attempts to redirect funds, the mismatch becomes obvious on the device.
6. Practical steps developers can take now
Lock dependency versions
Ensure that builds do not automatically install unreviewed updates.
Remove sensitive keys from environment variables
Use hardware-based signing or secure key services instead of storing private keys directly in CI or local configs.
Reduce unnecessary installation-time scripts
Disable unneeded workflows and post-install scripts in CI environments to minimize the risk of executing malicious code.
These practices are simple but effective, and significantly reduce exposure to supply chain attacks.
7. Closing thoughts
The two NPM incidents this year demonstrate that supply chains cannot be assumed to remain safe over time.
Even widely used dependencies can become attack vectors if a maintainer account is compromised.
We cannot control what happens upstream, but we can control how dependencies are used, reviewed, and deployed.
Reducing automatic updates, strengthening review processes, and ensuring that critical operations occur in trusted environments are currently the most reliable approaches.
Keeping the dependency chain transparent and manageable is far more effective than rushing to contain damage after an incident.
