A worm used stolen maintainer tokens to republish itself on npm

What happened

In September 2025, a self-replicating piece of malware researchers and GitHub itself named Shai-Hulud spread through the npm package registry by stealing publishing credentials from compromised maintainer accounts and using them to publish new, malicious versions of packages those maintainers controlled. CISA's alert, issued 23 September, says the compromise affected packages published after 16 September, harvested GitHub personal access tokens and cloud credentials from developer machines, and uploaded stolen material to a public repository the actor itself named after the malware. GitHub's own account, published a day earlier, says it removed more than 500 compromised packages and describes the malicious code as running automatically after installation. In response, GitHub committed to phasing out classic publishing tokens and one-time-password two-factor authentication in favour of hardware-backed methods, defaulting new packages against token-based publishing, and expanding trusted publishing, a mechanism that issues short-lived, workflow-specific credentials instead of long-lived tokens a maintainer must store and rotate manually.

Confidence and limits

The registry operator's own remediation account and an independent government alert agree on the mechanism, the malware's self-propagating behaviour and the rough scope of affected packages. Neither document puts a reliable number on how many downstream projects actually installed a compromised version, as opposed to how many packages were published maliciously, so any total-impact figure beyond the registry's own count should be treated as an estimate.

Why it mattered

A publishing credential is effectively a signing key for every consumer of a package, and this incident showed that a single stolen token can become many more through automatic republishing, without the attacker needing to compromise any additional maintainer directly. That self-replicating step is what distinguishes it from an ordinary compromised-package incident: the malware's own success expanded its reach faster than manual credential theft could. The registry's response treats long-lived, exportable tokens themselves as the underlying weakness, not just the individual accounts that were phished or otherwise compromised.

Defensive takeaway

Pin dependencies to versions published before 16 September 2025 pending your own review, rotate any credentials that could have been present on a developer machine running affected tooling, and move your own publishing workflows to short-lived, workflow-scoped credentials where your registry supports them.

• Do your build systems pin exact dependency versions, or do they pull whatever is newest at build time?
• Would your logging catch an outbound connection from a build step to an unfamiliar webhook or file-sharing endpoint?
• Are any of your own publishing credentials long-lived tokens stored in a configuration file rather than short-lived and workflow-scoped?

The registry's own response, moving away from exportable long-lived tokens by default, is the more durable outcome here than any single list of malicious package versions, since the credential model that enabled automatic republishing is what a future actor would otherwise reuse.