The npm Worm Era: Why Package Signatures Did Not Stop Shai-Hulud

In late 2025 a self-replicating worm known as Shai-Hulud moved through the npm ecosystem by stealing maintainer credentials and using them to publish malicious versions of packages those maintainers already owned. Reporting from Sonatype's supply-chain timeline records more than 180 compromised npm packages in that campaign. By May 2026 a related pattern appeared under the name TeamPCP or Mini Shai-Hulud, and the affected set included packages that security teams themselves depend on.
The uncomfortable part is not that a registry got poisoned. It is that the poisoned releases carried valid publisher credentials, which is exactly what integrity mechanisms are supposed to vouch for.

What the attacks actually exploited

The compromised versions were published by accounts that legitimately controlled the packages. Signatures and provenance attestations confirm who published a release, not whether that publisher intended to. When an attacker holds a maintainer token, every downstream control that asks 'was this released by the legitimate owner' answers yes.
The initial access in these campaigns has concentrated on the developer's environment rather than the registry. Documented vectors include compromised CI/CD workflows, malicious pull requests, typosquatted or dependency-confused packages that execute on install, hijacked maintainer accounts, and infostealer malware on developer endpoints. Reporting on the 2026 TanStack incident describes roughly 84 malicious versions across 42 packages in a six-minute window, later expanding to more than 170 packages and 404 malicious versions, with the campaign associated with CVE-2026-45321 and a CVSS score of 9.6.

Why install-time execution is the real problem

A package manager's install script is arbitrary code execution by design. Lifecycle hooks such as preinstall and postinstall exist so that native dependencies can be built, and any package that can run them can read the environment it is dropped into. In CI/CD that environment holds deployment keys, cloud provider tokens, registry passwords and database connection strings. A separate write-up of the Claude Code Action issue, tracked as CVE-2026-47751 and assigned in July 2026, describes the same shape of failure in a different component: a workflow that checked out an attacker-controlled pull request branch, read a configuration file from that branch and auto-approved the servers it declared, giving the contributor code execution on the runner. The trust model was wrong, so the cryptography never mattered.

Controls that change the outcome

• Pin and verify. Lock files with integrity hashes, internal mirrors that only serve reviewed versions, and admission checks that reject releases published outside an expected window all raise the cost of a poisoned release reaching production.
• Disable install scripts where you can. Not every project can, but the ones that can remove an entire execution primitive from the dependency path.
• Treat CI/CD as a privileged environment. Scope tokens per job, prefer short-lived workload identity over long-lived cloud keys, restrict who can trigger workflows that read secrets, and never auto-approve configuration from an untrusted branch.
• Watch the developer endpoint. Infostealers do not need a novel technique; they need a browser profile. Endpoint detection, browser extension allowlists and storage of tokens in a secrets manager rather than a dotfile are the practical countermeasures.
• Monitor for worm-like behaviour. A single account publishing to many packages in a short window, or new versions that add network calls at install time, is detectable without waiting for an advisory.

What to stop assuming

Provenance and signing answer 'which identity produced this artifact'. They do not answer 'did that identity mean to'. The 2025 and 2026 npm campaigns are a reminder that the weakest link in a package ecosystem is usually a human account with publish rights, and that the fastest way to that account is the laptop or pipeline that holds its token.

References

• Sonatype vulnerability timeline covering Shai-Hulud, the litellm PyPI compromise and axios npm incidents: https://www.sonatype.com/resources/vulnerability-timeline
• Analysis of the TanStack fork-poisoning campaign, affected package counts and CVE-2026-45321: https://m.freebuf.com/articles/ai-security/501983.html
• MITRE ATT&CK procedure examples referencing Shai-Hulud and TeamPCP supply-chain activity: https://attack.mitre.org/techniques/T1546/016
• Case study of hardcoded CI credentials leading to image and downstream compromise: https://blog.securemymind.com/information-security-defense-line-in-the-ai-era-from-real-cases-to-full-scale-action.html