The npm Ecosystem Is Burning Again

The npm Ecosystem Is Burning Again

Why Package Security Keeps Failing And What It Tells Us About Software Supply Chains

Introduction

Another day brings another incident in the npm ecosystem. The latest wave of the Shai Hulud campaign has compromised npm accounts linked to organisations such as Zapier, Postman, PostHog, ENS Domains and AsyncAPI. Researchers are tracking tens of thousands of GitHub repositories created with stolen developer credentials, hundreds of poisoned npm packages, and sensitive secrets exfiltrated and pushed back into public infrastructure.

It is tempting to view this as just one more breach to remediate. It is not. Shai Hulud and its current resurgence are the latest data points in a much larger pattern. That pattern includes targeted compromises of high-volume packages such as chalk and debug, a long running IndonesianFoods spam and worm campaign that flooded the registry with tens of thousands of fake Next style projects, and a token farming operation that uploaded more than one hundred and fifty thousand junk or malicious packages to game a blockchain reward scheme.

The uncomfortable conclusion is that we have built global software on top of an infrastructure that was never designed to carry this level of trust or value. The community has taken meaningful steps, but we are still a long way from addressing the structural weaknesses in the npm ecosystem.

What Shai Hulud Is Actually Doing

The original Shai Hulud campaign, disclosed in 2025, was one of the first truly large-scale self-propagating attacks against a modern package registry. A phishing campaign targeted npm maintainers, harvesting npm and GitHub credentials and then using those valid identities to push modified versions of popular packages. The malware focused on credential theft from developer workstations and build agents. Stolen secrets were then used to publish malicious updates to additional packages, allowing the worm to spread across the registry.

The current wave takes the same idea and industrialises it.

Account takeover and credential theft

Attackers compromise maintainer accounts through phishing or through previously stolen tokens. Malicious scripts harvest npm access tokens, GitHub personal access tokens and cloud provider credentials from environment variables, configuration files and continuous integration runner secrets. Once harvested, these credentials are sent to attacker infrastructure and reused to extend control.

Abuse of package lifecycle scripts

The payload is typically hidden in preinstall or postinstall hooks in package.json. When a developer or a pipeline runs npm install, the malware executes automatically with no further interaction beyond installing what appears to be a legitimate dependency. This gives the attacker reliable execution inside developer laptops and build systems.

New execution paths to evade monitoring

In the latest Shai Hulud wave, the actors dynamically install the Bun runtime and execute their payload through Bun rather than Node. This technique sidesteps monitoring stacks that only observe Node processes and allows a large, obfuscated payload to run in memory on developer machines and ephemeral runners.

Self propagation through CI and maintainer automation

With valid npm tokens, the malware enumerates packages owned by the compromised maintainer and publishes new versions with the backdoor embedded. It also traverses any GitHub repositories and automation it can reach, adding malicious workflows and configuration where possible. Each compromised project becomes a new launch point, allowing the campaign to propagate through the registry.

This is a classic supply chain compromise aligned with familiar techniques such as exploitation of trusted relationships and credential abuse inside developer tooling. The difference is the scale and automation. The worm uses the registry itself as its transport layer.

Shai Hulud Is A Symptom, Not The Disease

If Shai Hulud were an isolated incident, the remedy would be relatively straightforward: clean the packages, rotate secrets, enforce stronger authentication and move on. The challenge is that Shai Hulud arrives in an ecosystem that is already under sustained assault from multiple directions.

Recent examples include:

Targeted compromise of high download packages
Packages such as chalk and debug were compromised through maintainer account takeover and token theft, allowing attackers to insert malicious versions into libraries with billions of weekly downloads.
Registry flooding and worm campaigns
The IndonesianFoods campaign systematically published tens of thousands of fake packages over almost two years. Some of these artefacts contained worm behaviour that could generate yet more packages and lay the groundwork for future weaponisation.
Token farming and spam operations
More than one hundred and fifty thousand npm packages were created as part of a tea dot xyz token farming scheme. Many were functionally useless but polluted search results and dependency graphs and some displayed self replication characteristics of their own.

In other words, npm is not only being targeted by rare nation state level actors. It is being treated as a programmable platform for credential theft, fraud, spam and experimentation at scale.

Why npm Is Such An Attractive Target

There are several structural reasons why attacks on npm continue to produce returns for adversaries.

Massive scale and deep transitive dependencies

Npm is the default registry for Node and is widely used across front end tooling. It hosts millions of packages and receives tens of billions of weekly downloads. Modern applications routinely pull in hundreds or thousands of transitive dependencies. Compromising a single popular package can impact a very large blast radius downstream.

From an attacker perspective, npm looks like a global distribution network where:

A single maintainer credential can push code to thousands of organisations.
A single malicious update can move from a library to every consumer in hours through automated builds.

Weak identity and coarse trust boundaries

Historically, a single long lived npm token on a developer laptop granted broad publish rights to all packages under that maintainer. Multi factor authentication was optional and unevenly adopted. Migration to fine grained, least privilege tokens and stronger authentication is under way, but far from universal.

The trust model is essentially binary. You are either a maintainer, with the ability to publish, or you are not. There is limited native support for granular roles, approvals or enforced review workflows at the registry boundary. Once an attacker has a maintainer identity, the registry largely assumes good intent.

Unbounded execution through lifecycle scripts

Npm allows arbitrary code execution at install time through lifecycle scripts. This was designed as a convenience feature and is now a core part of many build pipelines. It also means that npm install is functionally similar to piping a remote script into a shell, simply wrapped in a more convenient interface.

Malicious use of lifecycle scripts appears in most major npm attacks. Disabling them outright would break many legitimate packages, and it is extremely difficult for the registry to determine whether a particular script is benign without executing it.

Thin governance and limited economic incentives

The registry is operated by GitHub, but most of the operational risk falls on enterprises and independent maintainers. Many critical packages are maintained by one or two volunteers with no dedicated security budget. Detailed dependency reviews, robust release processes and frequent credential rotation are largely unpaid work.

Attackers by contrast can monetise success through extortion, crypto theft, credential resale and now through direct manipulation of financial incentive schemes built on top of registry metrics. The tea token farming campaign demonstrates that it is possible to profit from registry abuse even without classical malware.

Why Our Responses Keep Falling Short

The broader ecosystem is not ignoring these incidents. GitHub has announced a roadmap for a more secure npm supply chain, including mandatory multi factor authentication for maintainers, shorter lived granular access tokens and expanded trusted publishing capabilities. Cloud providers and security vendors are publishing detailed technical analyses and new detection content for each wave.

However, the sense persists that we are not getting ahead of the problem. There are several reasons for this.

We treat each incident as an anomaly

Many security teams still handle supply chain compromise as an exception rather than an expected failure mode. Incident playbooks for endpoint or server compromise are mature. Equivalent playbooks for poisoned dependencies, compromised registries or malicious lifecycle scripts are much less common.

As a result, even sophisticated organisations lose valuable time simply establishing ownership. Teams debate whether a malicious dependency is an application security issue, a platform engineering issue, a cloud security problem or something for the open-source programme office. The attacker benefits from the ambiguity.

We invest in scanners rather than trust models

A common response to early package attacks was to invest in software composition analysis tools, generate software bills of material and wire vulnerability feeds into dashboards. Those capabilities are important, but they largely model risk as a static property of a package version expressed through CVE identifiers.

Shai Hulud and similar campaigns behave more like active intrusion sets. They use valid credentials, change behaviour over time and focus on exfiltrating secrets. A malicious postinstall script that exists in one release for a few days and then disappears may never be captured in a vulnerability database. Traditional CVE centric composition analysis does not reason well about that class of threat.

Registry and enterprise incentives are misaligned

Registry operators must preserve availability and compatibility for millions of projects. Aggressively disabling lifecycle scripts or enforcing very strict allow lists would break legitimate workflows at significant scale.

Enterprises, on the other hand, often assume that a central registry will behave like a curated application store. When that assumption fails, they discover that they need an additional control layer on top of npm, but they may not have budgeted for that investment.

Developer experience outweighs security friction

Controls that would materially improve resilience often introduce friction for developers and maintainers. Examples include mandatory hardware backed multi factor authentication, short lived scoped tokens for all automation, and internal registries that only expose vetted packages and versions.

These measures slow delivery in the short term. Without clear board level mandates or regulatory drivers, they are frequently diluted into optional recommendations. Attackers naturally route around the most secure paths and focus on the weaker ones.

What A More Realistic Approach Would Look Like

It is unrealistic to aim for a world in which malicious npm packages never exist. The attack surface is too large and the incentive model favours experimentation by adversaries. A more credible objective is to treat the public registry as hostile infrastructure and design systems with that assumption from the outset.

For registries

Make strong multi factor authentication and short-lived, fine-grained tokens the norm rather than an advanced configuration.
Expand trusted publishing so that maintainers can link releases to signed source artefacts and reproducible builds, limiting the scope for credential misuse.
Provide richer telemetry so that enterprises can see which identities, tokens and projects are interacting with which packages and where from.

For enterprises

Treat dependency management as a security control
Operate internal mirrors or private registries that cache approved versions and block direct installation from the public internet for production workloads.
Design continuous integration and developer environments as if dependencies are untrusted
Use ephemeral build runners with minimal secrets. Restrict outbound network access during installation steps. Monitor lifecycle scripts for suspicious behaviour such as access to credential stores or unexpected external connections.
Invest in supply chain risk as an explicit programme
Map critical business services to their dependency trees, including transitive packages and maintainers. Identify where single maintainer projects or single packages represent concentration risk and sponsor diversification strategies or direct support for those projects.

For development teams

Pin exact versions and maintain lockfiles so that you know precisely which release is in use when a compromise is disclosed.
Bias new development toward fewer dependencies and smaller frameworks where practical. Every additional transitive dependency is another maintainer account that could be compromised.
Normalise the idea that npm install is a risky operation. It should not run with powerful credentials or on privileged machines.

Conclusion

Npm has become one of the most important components of modern software infrastructure. It is also one of the most aggressively abused. Shai Hulud and its current wave of compromises against high profile organisations are not anomalies. They are the logical outcome of the trust model that the ecosystem has implicitly accepted.

We will continue to see worms, spam campaigns and fraud schemes that treat the registry as an experimental playground until we align incentives, strengthen identity and treat supply chain compromise as a standard element of the threat model rather than an unpleasant surprise.

Until that happens, every npm install in a production facing pipeline remains an act of optimistic trust in an ecosystem that determined adversaries have already shown they can bend to their will.

References