Source: Unit 42 — https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/
npm attacks are no longer background noise#
Unit 42’s updated npm threat landscape report describes a sharp change in the npm supply-chain threat model after the Shai-Hulud worm appeared in September 2025.
The important point is not just that malicious packages exist. That has been true for years. The change is that attackers are using npm as a distribution system for self-propagating compromise. The target is not one developer who installs one bad package. The target is the trust chain around package maintainers, GitHub accounts, npm tokens, CI/CD systems, and downstream users.
Unit 42 says the September 2025 Shai-Hulud incident marked the end of the “nuisance” era of npm attacks. Since then, it has tracked faster and more technically developed campaigns. The activity has moved beyond isolated typosquatting into campaigns that try to weaponize legitimate developer access.
The report points to two April 2026 campaigns. One began April 22 and included the string “Shai-Hulud: The Third Coming.” Another began April 29 and is known as Mini Shai-Hulud. Unit 42 says the Mini Shai-Hulud campaign continued with two new May waves attributed to TeamPCP, while also warning that copycat activity is making future attribution harder.
That caveat matters. Once worm code or campaign patterns become public, the same behavior can be reused by unrelated actors. Similar payloads and naming are not enough to prove a single operator.
What changed in the attack surface#
Unit 42 describes three broad shifts in npm adversary behavior after Shai-Hulud.
First, malicious payloads increasingly prioritize developer credentials. These include npm tokens and GitHub personal access tokens. The goal is not only theft. The goal is to use those credentials to infect and republish legitimate packages.
Second, attackers are moving into CI/CD systems. That changes the blast radius. A stolen secret from a developer laptop is serious. A foothold in a build pipeline can let an attacker touch release artifacts, package publishing workflows, cloud credentials, and automation that developers already trust.
Third, some attacks use dormant or conditional payloads. Unit 42 says current attacks can deploy “sleeper” dependencies that activate only under specific environmental conditions. This is a practical evasion method. Basic scanners may miss a package that does not behave maliciously in a generic sandbox.
The report also describes a malicious npm package impersonating the legitimate Bitwarden command-line interface. According to Unit 42, the package executed a multi-stage payload that stole credentials from cloud providers, CI/CD systems, and developer workstations. It then attempted to self-propagate by backdooring every npm package the victim could publish.
That is the modern npm risk in one sentence: a package install can become a publisher compromise.
Mini Shai-Hulud and the May 2026 waves#
Unit 42’s May update focuses on two further Mini Shai-Hulud waves.
The first wave introduced what Unit 42 describes as a new initial-access technique that did not require a stolen credential. It also produced malicious npm packages with valid SLSA provenance. That detail is important because provenance is often treated as a strong trust signal. It still helps. But it does not prove the upstream workflow was safe if the workflow itself was abused.
The second wave produced what Unit 42 calls the largest single-hour package count of any Shai-Hulud wave to date.
For the May 11 activity, Unit 42 says TeamPCP launched a coordinated supply-chain attack across npm and PyPI. The initial vector was TanStack’s GitHub Actions CI pipeline. Within six minutes, 84 malicious package artifacts were published across 42 packages. By the end of the day, Unit 42 had documented 373 malicious versions across 169 npm packages, plus compromised PyPI packages.
The affected scope was not limited to TanStack. Unit 42 says the worm’s self-propagation spread compromise to packages across multiple industries and ecosystems. The report names enterprise infrastructure packages, including @opensearch-project/opensearch, the official OpenSearch JavaScript client, and also references enterprise automation packages and cloud variants. It also mentions the official Mistral AI TypeScript client and other packages.
Unit 42 estimates 520 million cumulative downloads during the affected window. That number should be read as exposure scale, not as confirmed compromise count. Downloads do not equal successful execution. But they show why registry-level compromise can move fast.
Why the “no stolen credential” claim matters#
Earlier Shai-Hulud waves reportedly began with stolen or phished credentials. The TanStack-related attack described by Unit 42 was different.
Unit 42 says the attacker did not need a stolen credential. Instead, the attack chained three GitHub Actions weaknesses. None was sufficient alone.
The report says the attacker created a fork of a repository on May 10, naming it in a way intended to avoid appearing in fork-list searches. A malicious commit was authored under a spoofed identity, “claude claude@users.noreply.github.com,” impersonating the Anthropic Claude GitHub App. The commit was also prefixed to suppress automated CI on push.
The source excerpt available here cuts off before the full chain is described. So the safe conclusion is limited: Unit 42 attributes the initial access to abuse of GitHub Actions workflow behavior rather than direct credential theft. The broader lesson is still clear. CI configuration is part of the supply chain. It is not a side issue.
Valid provenance and automated release workflows can become misleading if the automation path can be manipulated. A signed or provenance-linked artifact is stronger than an unsigned one. But it is not magic. It answers where the artifact came from. It does not always answer whether the process that produced it was abused.
What defenders should check now#
For teams that publish or consume npm packages, the practical response should focus on identity, automation, and cached artifacts.
Start with publisher credentials. Rotate npm tokens and GitHub personal access tokens that may have been exposed through developer machines, CI logs, package scripts, or build environments. Prefer short-lived and scoped tokens where possible. Broad, long-lived publishing tokens are high-value worm fuel.
Review GitHub Actions workflows. Pay special attention to pull request triggers, fork behavior, reusable workflows, release automation, and any job that receives secrets or can publish packages. A workflow that can be influenced by untrusted code should not also hold publishing authority.
Check package publishing rights. Many projects accumulate maintainers, automation accounts, and legacy tokens. Remove anything that no longer needs release access. Treat npm publisher permissions like production access.
Audit recent package versions. Look for unexpected releases, unusual publish timing, unfamiliar maintainers, new lifecycle scripts, and changes to install-time behavior. Do not inspect only direct dependencies. Self-propagating package attacks can move through transitive paths and maintainer accounts.
Purge suspicious cached artifacts. Local developer caches, CI caches, internal mirrors, and cloud build caches can keep malicious versions alive after the public package is removed. Registry cleanup does not automatically clean every downstream environment.
Watch for credential access after install. Package lifecycle scripts that enumerate environment variables, cloud configuration files, npm credentials, GitHub tokens, SSH keys, or CI secrets deserve immediate attention.
What not to overclaim#
This report does not mean every npm install is compromised. It also does not mean SLSA provenance is useless. It means the trust boundary has moved.
The old mental model was simple: avoid obvious typosquats and known malicious packages. That is no longer enough. A legitimate package can become malicious if its maintainer account, publishing token, or release pipeline is compromised. A package with provenance can still be dangerous if the workflow that created it was tricked into producing the wrong thing.
Attribution should also be handled carefully. Unit 42 attributes the Mini Shai-Hulud waves to TeamPCP, but notes that public release of the worm’s source code has already produced copycat activity. Future incidents may reuse the same patterns without coming from the same operator.
The useful response is not panic. It is a stricter trust model.
Treat npm publishing as production infrastructure. Treat CI as an identity boundary. Treat package provenance as one signal, not the final answer. And assume that any credential reachable from a package install path is a credential attackers will try to turn into distribution power.