NPM worms, credential harvesting and 2 billion weekly downloads: supply-chain attacks have professionalised

A self-replicating worm recently infected at least 187 JavaScript packages in the NPM registry, as reported by Phylum. Every time someone installed one of the compromised packages, the malware harvested the developer's credentials and republished them to GitHub. Separately, 18 popular JavaScript packages, collectively downloaded over 2 billion times per week, were compromised after their maintainers fell for a coordinated phishing campaign, according to Socket. The payloads focused on stealing cryptocurrency. These are not isolated incidents. They are symptoms of an attack class that has quietly industrialised while the security community was still debating whether software bills of materials would solve the problem.

The worm that builds itself

The NPM worm is notable not for its sophistication but for its architecture. Traditional supply-chain attacks require an attacker to compromise a package, inject a payload and hope the package gets installed widely enough to matter. This worm eliminated the distribution problem entirely. Once a developer installed an infected package, the malware exfiltrated their NPM credentials, used those credentials to publish malicious versions of every package the developer maintained and repeated the cycle. Each new victim became a distribution node.

The credentials were not quietly siphoned to a command-and-control server. They were published to GitHub, visible to anyone watching the right repositories. This is either operational sloppiness or a deliberate choice to create a public credential dump that other actors would readily exploit. Either interpretation is uncomfortable: the first suggests the worm spread despite poor tradecraft, and the second suggests the operator was building a shared resource for the broader criminal ecosystem.

At least 187 packages were confirmed infected. The actual number is almost certainly higher. NPM's malware detection capabilities have improved in recent years, but a worm that propagates through legitimate maintainer credentials is publishing packages that look, to every automated system, like routine updates from trusted authors.

Developer phishing at scale

The phishing campaign that compromised 18 high-download packages operated on a different model but targeted the same weak point: the maintainer. Rather than automating credential theft through malware, the attackers went after developers directly, using social engineering to obtain access tokens or session cookies.

Two billion weekly downloads is a staggering blast radius. A single malicious release of a package at that scale reaches more machines in a day than most botnets accumulate in a year. The attackers understood this. The payloads were focused, targeting cryptocurrency wallet credentials and browser-stored secrets rather than deploying noisy ransomware or establishing persistent access. This is smash-and-grab at software-infrastructure scale.

What connects the worm and the phishing campaign is the target: not the code, but the human who publishes it. Package registries authenticate publishers. They do not, in any meaningful sense, authenticate the intent behind a publication. If a maintainer's credentials are valid, the package is accepted. If the package passes basic linting and does not match known malware signatures, it is served to every downstream consumer without further inspection.

The commit signing gap

A study published this month on arXiv (Analysis of Commit Signing on GitHub) examined 71,694 active GitHub users across all their repositories and found that commit signing practices are deeply inconsistent. A developer who signs commits in one repository may not sign them in another. The study frames this through replicability theory: by varying the sampling unit from repositories to individual developers, the authors reveal that platform-wide signing behaviour is far more fragmented than repository-level studies suggest.

This matters because commit signing is one of the few mechanisms that could, in theory, provide a cryptographic chain of trust from developer intent to published artifact. If a maintainer's NPM token is stolen but their commits are unsigned, there is no way to distinguish a legitimate release from a malicious one. If their commits are signed but only in some repositories, the signal is unreliable. And if signing is inconsistent across the platform, automated verification systems cannot treat an unsigned commit as suspicious without generating an unmanageable volume of false positives.

The paper does not argue that commit signing is useless. It argues that the current adoption pattern renders it ineffective as a platform-wide trust signal. This is a structural problem, not a tooling problem. The tools exist. The incentives to use them consistently do not.

The attack surface is wider than package registries

The incidents described above target NPM, but the same operational model is playing out across every software distribution mechanism that relies on maintainer credentials as the primary trust boundary.

Browser extensions occupy a similar position. A compromised extension update is pushed to millions of users through a trusted distribution channel, with the same authentication model: if the developer's credentials are valid, the update is served. WordPress plugins follow the same pattern. CI/CD systems like GitHub Actions, which I have written about previously, allow a single compromised action to execute arbitrary code in every workflow that references it.

What has changed in 2026 is not the existence of these attack surfaces. It is the operational maturity of the actors exploiting them. The NPM worm is not a proof of concept. It is a production system with automated credential harvesting, automated propagation and automated exfiltration. The phishing campaign against JavaScript maintainers was not a lone actor trying their luck. It was a coordinated operation targeting specific high-value packages for maximum downstream impact.

This is what professionalisation looks like. The attackers have moved from opportunistic compromise to systematic exploitation of trust relationships. They understand dependency graphs. They understand which packages offer the highest ratio of downstream consumers to maintainer security maturity. They understand that a maintainer who reuses passwords, does not enable multi-factor authentication, or clicks a well-crafted phishing email is the cheapest entry point into thousands of production environments.

Why the defences are not keeping pace

The security community's response to supply-chain attacks has been largely structural: SBOMs, dependency pinning, hash verification, Sigstore, SLSA frameworks. These are good ideas. None of them address the central vulnerability that the NPM worm and the phishing campaign exploited.

SBOMs tell you what is in your dependency tree. They do not prevent a trusted maintainer from publishing a malicious update. Dependency pinning prevents automatic upgrades to compromised versions, but only if you never update, which creates its own security debt. Hash verification confirms that the artifact you received matches the artifact that was published, which is unhelpful when the published artifact is itself malicious. Sigstore and SLSA provide provenance guarantees, but only when adopted, and the commit signing study demonstrates how far adoption is from universal.

The uncomfortable truth is that every one of these defences assumes the publisher is acting in good faith. They verify that the artifact came from where it claims to come from. They do not verify that the person who published it intended to publish it, was not coerced into publishing it, or had not already had their credentials stolen.

Multi-factor authentication on package registry accounts is the single most effective mitigation available today, and it is still not mandatory on most registries. NPM introduced mandatory 2FA for high-impact packages in 2022. Four years later, the policy covers only a fraction of the registry. PyPI has followed a similar trajectory. RubyGems, crates.io and most other registries have even less coverage.

The economics favour the attacker

There is a structural asymmetry in supply-chain security that no framework or tool can fully resolve. A defender must secure every maintainer account, every CI/CD pipeline, every package publication workflow and every distribution channel. An attacker needs to compromise one.

The NPM worm demonstrates how that asymmetry compounds. One compromised developer yields credentials for every package they maintain. Each of those packages, once infected, compromises every developer who installs it. The growth is geometric. The defender's cost is linear: each additional maintainer requires individual onboarding, training, credential management and monitoring. The attacker's cost decreases with each successful propagation.

This is not a problem that better tooling will solve in isolation. The package registry model was designed for convenience and collaboration. It assumes a community of good-faith participants and provides mechanisms for publishing, versioning and dependency resolution. Security was retrofitted, and the retrofitting has been impressive in places, but the fundamental trust model remains: if you have the credentials, you can publish.

What would actually help

Three changes would materially reduce the blast radius of supply-chain attacks, though none is easy to implement.

First, mandatory multi-factor authentication for all package registry accounts, not just high-impact ones. The NPM worm propagated through maintainers of relatively obscure packages. Popularity is not the only measure of risk. Any package in a dependency chain is a potential propagation vector.

Second, publication anomaly detection that goes beyond malware signatures. A maintainer who has published once a month for three years and suddenly publishes four updates in an hour, from a new IP address, with obfuscated post-install scripts, should trigger a hold for review. Some registries are moving in this direction. None have deployed it at the granularity needed to catch the patterns described here.

Third, a cultural shift in how the industry values maintainer security. Open-source maintainers are responsible for code that runs in millions of production environments. Most of them receive no compensation, no security training and no organisational support. Expecting them to maintain operational security at the level of a corporate development team, while providing none of the resources that corporate teams receive, is a policy choice. It is one the industry has made by default rather than by design, and the consequences are now playing out at scale.

The cheapest way into a modern software supply chain is not a zero-day in a build system or a sophisticated compiler trojan. It is a phishing email sent to someone who maintains a package you have never heard of but your application depends on transitively. That has been true for years. What has changed is that the attackers have noticed.