Every time a developer types npm install, they are placing a bet that the package they are pulling into their project is not laced with malicious code. In 2025, those odds got significantly worse. Detections of malicious packages hidden inside freely available open-source libraries jumped 73% year over year, according to ReversingLabs research published in January 2026. That figure reflects one vendor’s proprietary scanning telemetry rather than an industry-wide census, but ReversingLabs’ position as a supply-chain security specialist with direct access to package registry data gives its numbers meaningful weight. The surge landed hardest on npm, the default package manager for JavaScript and one of the largest code registries on the planet, raising urgent questions about how the open-source ecosystem polices what gets published.
npm bore the brunt of the surge
The 73% spike was not spread evenly. ReversingLabs found that npm accounted for the heaviest concentration of malicious packages, a reflection of the registry’s massive scale and the relative ease with which anyone can publish code there. With millions of packages powering both front-end and back-end JavaScript development worldwide, npm offers attackers an outsized blast radius: poison one popular dependency, and the malicious code can cascade into thousands of downstream projects.
What makes the finding more striking is the contrast with two other major registries. PyPI, the primary repository for Python packages, and NuGet, the .NET ecosystem’s package manager, both saw declines in malicious uploads during the same period. ReversingLabs attributed those declines to platform-level controls such as mandatory two-factor authentication for maintainers and trusted publishing workflows that verify a package’s build provenance before it reaches end users. However, neither PyPI nor NuGet has published a specific announcement confirming that these measures were responsible for the decline, so the causal link remains ReversingLabs’ interpretation rather than a registry-confirmed finding.
The takeaway is hard to miss. Registries that enforced concrete security requirements saw fewer malicious packages. The one that did not saw a 73% increase.
What these malicious packages actually do
For readers outside the software industry, it helps to understand what is at stake when a malicious package slips into a registry. These are not theoretical risks. Poisoned packages have been caught deploying credential stealers that harvest API keys and login tokens, installing cryptominers that hijack server resources, and opening backdoors that give attackers persistent access to corporate networks. In some cases, the malicious code activates only after installation, making it harder to catch during a routine code review.
The open-source supply chain has already produced high-profile scares. The XZ Utils backdoor discovered in March 2024, in which a patient attacker spent years gaining maintainer trust before inserting a sophisticated backdoor into a widely used compression library, demonstrated how deeply supply-chain compromises can penetrate critical infrastructure. The 73% detection increase reported by ReversingLabs suggests the broader ecosystem is moving in the same dangerous direction, even if most of the newly detected packages are less sophisticated than the XZ Utils case.
Federal vulnerability tracking is falling behind
The surge in malicious packages arrives at a particularly bad time for the government systems that help defenders prioritize threats. In April 2026, NIST announced it was updating operations at the National Vulnerability Database to address record growth in CVE submissions. The NVD is the federal clearinghouse where newly discovered software vulnerabilities receive severity scores and enrichment data that security teams across the country use to decide what to patch first.
When that pipeline backs up, the consequences are practical and immediate. A malicious or vulnerable dependency might be identified by a scanning tool, but if the corresponding NVD entry has not been enriched with severity and impact data, security teams are left guessing how urgently they need to act. The backlog effectively widens the window during which organizations remain exposed.
For smaller development shops that rely solely on NVD data for patch prioritization, the delays are especially punishing. Larger enterprises can supplement with commercial threat intelligence feeds and vendor advisories, but that option requires budget and staffing that many teams simply do not have.
Defenses that are working and ones that are not
The ReversingLabs findings offer a natural experiment in what works. PyPI’s rollout of mandatory two-factor authentication for all maintainers and NuGet’s adoption of trusted publishing workflows both correlated with declining malicious upload volumes. These are blunt, registry-wide controls that do not depend on every individual developer making the right security choices downstream.
On the framework side, NIST SP 800-218, the Secure Software Development Framework version 1.1, lays out detailed practices for dependency management, package provenance verification, and secure build pipelines. It is widely referenced in U.S. federal procurement requirements and enterprise security policies. But the framework is voluntary for most of the private sector, and no public data tracks how many organizations have fully implemented its recommendations.
At the individual team level, the baseline defensive playbook has become more demanding. Automated dependency scanning, lockfile pinning to prevent silent updates, and signature verification on packages are no longer optional hygiene steps. They are minimum requirements for any project with npm dependencies. Teams that previously treated supply-chain attacks as edge cases now have hard numbers showing the risk is systemic.
What the data does not tell us
Important gaps remain. The ReversingLabs report quantifies detection volume but does not publish data on how many organizations were actually compromised by the flagged packages, or what remediation cost them. No authoritative source has attached verified dollar figures to the 2025 surge specifically.
It is also unclear who is behind the increase. Without case-level attribution, there is no way to distinguish between a small number of sophisticated, possibly state-sponsored campaigns and a broad rise in low-effort poisoning attempts by financially motivated criminals. Both scenarios demand different defensive responses, and the current data does not separate them.
Perhaps most critically, npm’s parent organization has not made public statements detailing what specific countermeasures it plans to deploy. Whether the registry will follow PyPI and NuGet in mandating two-factor authentication or trusted publishing at scale remains an open question as of June 2026.
Why the burden now falls on the teams building software
Until stronger, enforceable standards are in place across the major registries, the math is straightforward: malicious packages are more common, the federal systems that catalog vulnerabilities are under strain, and the most comprehensive security framework available functions as a recommendation rather than a mandate.
That leaves the burden of defense squarely on the organizations consuming open-source code. Development teams that mirror external packages into vetted internal repositories, enforce review gates for new dependencies, and flag anomalous maintainer behavior are better positioned than those still pulling directly from public registries without additional checks. The registries that imposed controls saw results. The ones that did not saw a surge. For anyone shipping software built on open-source components, that contrast should be driving decisions right now.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
