Malicious Packages Rose 73% and One Registry Absorbed Almost All of It

A 73% rise in malicious open source packages sounds like a story about open source. Read the breakdown in the ReversingLabs 2026 Software Supply Chain Security Report and it is a story about one registry. Malicious activity in npm more than doubled during 2025 and accounted for nearly 90% of everything detected. Over the same period PyPI detections fell 43% and NuGet fell 60%. Two of the three major ecosystems got measurably safer.

That divergence is the useful part, because it means the increase is not an inevitable consequence of open source consumption. Something specific about npm, or about how npm is defended, is producing a different outcome from Python and .NET. Any security programme that responds to the 73% by adding blanket controls across every language has misread the data.

Why npm and Not the Others

The mechanics are structural rather than cultural. npm packages are small, numerous and deeply transitive, so a single direct dependency can pull in hundreds of indirect ones and the dependency graph of a modest front-end application runs to thousands of packages. Publishing is fast and largely unmediated. Install-time scripts execute code by design, which means malicious behaviour does not have to wait for a developer to import anything. And typosquatting works better where package names are short and the namespace is flat.

The Shai Hulud worm is the demonstration. Across two campaigns it compromised more than 1,000 npm packages and exposed an estimated 25,000 GitHub repositories. A worm is a meaningful escalation from a malicious package: it means compromise propagates through the ecosystem on its own, using developer credentials harvested from one victim to publish to the next. That is a supply chain attack with a reproduction rate, and it is only possible where publishing is fast and credentials are plentiful.

“AI has increasingly fueled modern software development, simultaneously populating libraries and emboldening attackers.”

Tomislav Peričin, Chief Software Architect and co-founder, ReversingLabs

ReversingLabs frames the wider point bluntly: software supply chains have stopped being a niche target and have become one of the most exploited attack surfaces in security. What the registry split adds is that the exploitation is not evenly distributed, and the difference between a registry where detections doubled and two where they fell by 43% and 60% is a difference in defensibility rather than in attention.

The AI Complication Runs Both Ways

Assistants that suggest dependencies have made it easier to acquire packages a developer has not evaluated, and package names hallucinated by a model are a novel and well-documented squatting opportunity. Less discussed is the volume effect: more code written faster means more dependency additions per sprint, and dependency review was already the step teams skipped when under pressure.

Set against that, the same tooling is what makes review tractable at all. Nobody is reading 3,000 transitive packages by hand. The realistic posture is automated provenance checking at install time rather than human judgement at review time, which is a different investment from the code scanning most organisations already own.

It is worth being careful about what a falling detection count means. Fewer detections in PyPI could reflect better registry defences, or a shift in attacker attention toward the larger prize, or simply less scanning. The report does not settle that, and treating a decline as proof of safety is the same error as treating npm's rise as proof that JavaScript developers are careless.

What Actually Reduces Exposure

The controls that work here are unfashionable. Lockfiles that are actually enforced in continuous integration rather than regenerated on every build. Disabling install scripts by default, which breaks a small number of packages and removes an entire attack class. An internal registry proxy so that what reaches a build machine is a reviewed mirror rather than whatever was published four minutes ago. And build-time provenance, so a package that changed maintainers or publishing infrastructure produces a signal rather than a silent update.

None of that is where security budgets naturally go, because it lives in build infrastructure rather than in a security product, and it is owned by platform engineering rather than by the security team. That ownership gap is a better explanation for the npm figure than any claim about open source hygiene.

• Read the registry breakdown, not the headline. With PyPI down 43% and NuGet down 60%, controls should be weighted toward the JavaScript estate rather than applied uniformly across every language.
• Disable install scripts by default. They are why a malicious npm package runs without being imported. Allowlisting the handful of packages that genuinely need them is a day of work.
• Proxy the registry. A reviewed internal mirror puts a delay and a decision between publication and your build machines, which is what a worm with a reproduction rate needs removed to spread.
• Alert on maintainer and provenance changes. Shai Hulud spread using harvested publishing credentials. A change of publisher on an existing package is a stronger signal than any static scan of its contents.
• Put this in the platform team backlog, not the security one. These are build pipeline controls. Filed as security work they compete with detection spend and lose; filed as engineering reliability they get done.

The interesting number in this report is not 73%. It is the two registries where detections fell, which between them demonstrate that the direction of travel in a software ecosystem is a set of decisions rather than a force of nature.