Why npm package signatures did not stop the Shai-Hulud worm

A self-replicating worm known as Shai-Hulud moved through the npm registry in late 2025 by hijacking maintainer accounts and pushing malicious updates to packages those same maintainers already controlled. According to a dev.to analysis drawing on Sonatype's supply-chain timeline, the campaign compromised more than 180 npm packages, and by May 2026 a successor pattern labelled TeamPCP, or "Mini Shai-Hulud", had appeared — reaching packages that security teams themselves depend on.

The unsettling detail, the write-up argues, is not simply that a registry was poisoned. It is that the poisoned releases carried valid publisher credentials, which is exactly what integrity mechanisms are supposed to vouch for. Nothing in the credential chain was forged; the attacker simply held the keys.

How the credentials were taken

Initial access concentrated on the developer's environment rather than the registry itself. Documented entry routes include compromised CI/CD workflows, malicious pull requests, typosquatted and dependency-confused packages that execute at install time, hijacked maintainer accounts, and infostealer malware on developer machines.

The 2026 TanStack incident shows how fast this plays out. As reported in the dev.to analysis, roughly 84 malicious versions landed across 42 packages in a six-minute window, later expanding to more than 170 packages and 404 malicious versions. The episode was assigned CVE-2026-45321 with a CVSS score of 9.6.

The core weakness is conceptual: signatures and provenance attestations establish who published a release, never whether they meant to. Once an attacker controls a maintainer token, every downstream control asking whether a release came from the rightful owner returns yes.

Why install scripts magnify the damage

Lifecycle hooks such as preinstall and postinstall exist so native dependencies can be compiled, which makes them arbitrary code execution by design. Any package that runs them can read the environment it lands in — and in CI/CD that environment holds deployment keys, cloud provider tokens, registry passwords and database connection strings.

The analysis points to a parallel failure elsewhere in the toolchain: the Claude Code Action flaw tracked as CVE-2026-47751, assigned in July 2026. A workflow there checked out an attacker-controlled pull request branch, read a configuration file from that branch, and automatically approved the servers the file declared — handing the contributor code execution on the runner. In both cases the trust model was already broken before any cryptography entered the picture.

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 possible: projects that can drop them remove an entire execution primitive from the dependency path.
• Treat CI/CD as privileged: 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.
• Harden the developer endpoint: infostealers need no novel technique, only a browser profile. Endpoint detection, browser extension allowlists, and storing tokens in a secrets manager rather than a dotfile are the practical countermeasures.
• Watch for worm-like behaviour: one 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.

Why it matters

Provenance and signing answer which identity produced an artifact; they cannot answer whether that identity consented. The npm campaigns of 2025 and 2026 are a reminder that the weakest link in a package ecosystem is usually a human account with publish rights, and the fastest route to that account runs through the laptop or pipeline holding its token. Registry-side integrity tooling only helps when publisher-side access control is equally strong — a lesson that extends to every registry and build system built on the same trust assumptions.