NPM Supply Chain Attacks

Software supply chain attacks aren’t new, but the JavaScript ecosystem and specifically NPM has become the perfect breeding ground for them.

With millions of packages, heavy dependency chaining, and a culture of rapid development, NPM has unintentionally created one of the largest attack surfaces in modern software engineering.

When you combine this with the fact that almost every web application, CI pipeline, and cloud service pulls packages dynamically, you get a security nightmare: one compromised package can cascade across thousands of organizations within hours.

This article breaks down how NPM supply chain attacks work, why they’re so effective, and what cyber security teams should be focusing on in 2025.

NPM Supply Chain Attacks: Why NPM Is a Perfect Target

The biggest issue is simple: the average NPM project doesn’t actually depend on 5–10 packages it depends on hundreds. A typical install chain pulls in dozens of transitive dependencies you’ve never heard of, written by people you’ll never meet, maintained with a level of security that ranges from “fine” to “this hasn’t been updated in six years”.

The best part? The developers pulling down from these packages have very little security training and are under extreme pressure to push out new projects FAST.

This creates three permanent realities for defenders:

Developers do not review 99% of the code they run.
Attackers understand the ecosystem better than the teams using it.
A single compromised maintainer account can be more valuable than a zero-day.

When you publish an NPM package, thousands of downstream developers may implicitly trust you. If an attacker compromises your account or injects malicious code into your repo, that trust is instantly weaponised.

Organisations relying on open-source npm packages face significant risks when their supply chains are compromised.

How NPM Supply Chain Attacks Happen

Before executing more complex attacks, threat actors often focus on gaining initial access to npm projects through methods such as credential harvesting, phishing, or exploiting vulnerabilities.

There are several repeatable patterns attackers use. Most NPM compromises fall into one of these categories:

1. Compromised Maintainer Accounts

Attackers compromised a developer’s account, which is the classic and still the most successful method of npm supply chain attacks. Maintainers often use weak passwords, lack MFA, or store NPM tokens on disk where malware can extract them. Once a compromised developer account is accessed, attackers simply publish a new version of the package with malicious logic.

This is exactly how the ua-parser-js incident unfolded, where attackers compromised the developer’s account through a targeted phishing campaign, allowing them to distribute malicious code. Attackers pushed versions that installed cryptominers and credential stealers on user machines. No vulnerability was required just account access. The blast radius came from the fact that this single package had over 7 million weekly downloads.

2. Dependency Hijacking (a.k.a. Orphan Packages)

If a project is abandoned or the owner’s domain expires, attackers can take it over.
Maintainers frequently use custom domains for email verification. When those domains lapse, attackers buy them, reset the NPM password, and publish malware under a legitimate-looking name with a clean history.

This technique is cheap, fast, and incredibly effective because:

Nobody monitors old dependencies.
The package version history looks legitimate.
Dev teams rarely pin versions correctly.

Hijacking a dead package with 30k weekly downloads is far easier than building malware from scratch.

3. Typosquatting

Attackers publish malicious packages with names almost identical to popular ones:

expresss instead of express
react-tils instead of react-utils
lodash-es6 instead of lodash

Developers make mistakes, and CI pipelines often install whatever is written in the manifest. Attackers only need a single developer in a major organization to fat-finger a command for the compromise to spread.

NPM attempts to detect typosquatting, but the scale of the registry makes enforcement inconsistent.

4. Dependency Confusion

This technique exploits how package managers choose between internal and public packages.
If your organization has a private package called @company/logger but your CI/CD doesn’t strictly enforce private registries, an attacker can publish a public package with the same name usually with a higher version number. Some build systems will happily download the attacker’s version.

This attack gained traction after Alex Birsan’s 2021 research, and it hasn’t slowed down. It remains one of the easiest ways to breach large enterprises with poorly segmented build environments.

5. Malicious Post-Install Scripts

NPM allows packages to run scripts automatically during installation. If a package contains a post-install script that:

steals environment variables
exfiltrates SSH keys
modifies PATH
runs a backdoor binary

These scripts can leverage an automated process to scan the local filesystem for secrets and use browser APIs to intercept sensitive data.

…that code executes before the developer even imports the library. This makes post-install scripts one of the most dangerous features in the entire ecosystem.

Many large organizations now block packages with install scripts unless explicitly allow-listed.

What Attackers Usually Aim to Steal

Attackers often target sensitive credentials, including cloud credentials, which can be harvested and used for further attacks with harvested credentials.

Depending on the threat actor, goals differ. But across most attacks, the common themes include:

Credential Harvesting

Developers are an attractive target. Their machines often hold:

GitHub/GitLab PATs
Cloud access keys
NPM tokens
SSH keys
OAuth refresh tokens

Stealing these allows lateral movement and further supply chain poisoning.

Cryptomining & Resource Abuse

Low-skill attackers often opt for cryptomining payloads because they:

are easy to deploy
An infected machine can be quickly repurposed for cryptomining, maximizing the attacker’s profit.
don’t require stealth
monetize compromised machines quickly

This is especially tempting when CI servers with huge CPU budgets are compromised.

Data Exfiltration

Some malicious packages quietly steal:

source code
environment variables
configuration files
secrets in .npmrc, .env, or keychain stores

This intelligence is then used for targeted intrusions against the organization.

Building Secondary Access

More sophisticated actors add persistence or lateral movement capability.

For example:

modifying shell configs
planting RATs
adding SSH keys
altering global node modules

By establishing persistence, attackers can maintain ongoing control over the compromised machine, ensuring the environment remains under the attacker’s control.

A single malicious dependency can effectively bootstrap a full endpoint compromise.

Why These Attacks Are So Effective

NPM supply chain attacks work because they exploit trust, not vulnerabilities. The ecosystem encourages speed over scrutiny. Teams rarely have time to audit dependencies, and build pipelines automatically fetch updates without reviewing changes.

Some specific structural issues:

Massive dependency chains — a small package can be transitively required by thousands of others.
Over-frequent updates — npm packages push updates daily; review is unrealistic.
Automation-first culture — CI/CD pipelines install dependencies automatically, often with elevated privileges.
Poor version pinning — floating versions (^1.2.3, ~3.4.0) open the door for malicious updates.
Lack of maintainer accountability — many popular packages are maintained by one person in their spare time.

Attackers often abuse a legitimate tool software originally intended for benign or productive use to perform malicious activities, making detection even more challenging.

Attackers don’t need zero-days, they just need initial access to a maintainers account.

Indicators of Compromise and Detection

Spotting trouble in the npm ecosystem isn’t always straightforward, and trust me, I’ve learned this the hard way over my years of working with dependency chains. The sheer volume of npm packages and the complexity of modern dependency chains mean that malicious packages and compromised versions can slip through unnoticed until it’s way too late.

So, what should you look for? Attackers leave traces everywhere, and realistically, the npm registry is packed with telltale signs if you know where to look. Some of the most common IoCs include:

Malicious packages published to the npm registry, often masquerading as legitimate dependencies or updates (I’ve seen this more times than I can count).
Compromised versions of popular npm packages (like ansi-styles), where malicious code gets injected into trusted software dependencies.
Unusual outbound connections from developer machines or build pipelines to suspicious domains, which may indicate data exfiltration or command-and-control activity happening right under your nose.
Stolen credentials and API keys being used to access cloud services such as Google Cloud Platform, often harvested via malicious post-install scripts or infected packages.
Unexpected changes in package lock files or the sudden appearance of new dependencies, which can signal a compromised package or a supply chain attack that’s already in progress.
Malicious post-install scripts that attempt to access environment variables, await fetch requests to attacker-controlled servers, or execute arbitrary code on critical platforms.

One particularly nasty threat is the Shai-Hulud worm, which has shown us exactly how a self-replicating worm can wreck the npm ecosystem by injecting malicious code into npm packages and using stolen npm tokens to publish malicious versions. This worm leverages GitHub Personal Access Tokens to access private repositories, spreading like wildfire across affected dependencies and organizations.

Security teams should:

Monitor for anomalous network activity and outbound connections from build pipelines and developer machines.
Watch for the use of stolen credentials, such as npm tokens or GitHub Personal Access Tokens, especially in connection with private repositories or cloud services.
Regularly audit npm packages and dependencies for signs of compromise, including unexpected changes in package lock files or npmrc files.
Be alert to targeted phishing campaigns aimed at maintainer accounts, which can lead to credential harvesting and further npm compromise.
Investigate any suspicious activity in user home directories, configuration files, or environment variables that could indicate data theft or arbitrary code execution.

False positives are inevitable, especially when you’re scanning for malicious post-install scripts or changes in lock files. But trust me it’s far better to investigate a false alarm than to miss a real npm attack that could compromise your entire software supply chain.

Organizations should:

Stay informed with the latest threat intelligence on new vulnerabilities, malicious packages, and supply chain attacks targeting the npm ecosystem.
Implement automated monitoring and alerting for suspicious activity across all critical platforms and build pipelines.
Regularly update and audit all npm packages and dependencies to minimize the risk of malicious actors exploiting vulnerable packages.
Use security tools and best practices—such as strict package lock files, npmrc configuration, and environment variable monitoring—to prevent the installation of compromised packages.

In the end, defending against npm supply chain attacks is an ongoing process that never really stops. By understanding the indicators of compromise, staying vigilant, and leveraging the right security measures, organizations can protect their software dependencies and maintain the integrity of their software supply chain even as attackers continue to evolve their tactics and get more creative with their approaches.