Is npm Safe? A Practitioner Guide to npm Security in 2026

May 2026

Is npm safe to use in 2026? Yes, but the threat model has shifted. The risk in 2025-2026 is no longer the obvious malicious package, it is the trust-flow exploit: attackers compromise the developer's implicit trust in the registry, the maintainer, or the dependency tree itself.

The defence is an explicit-trust workflow. Where modern software trusts each link in the supply chain by default, this workflow makes every trust decision deliberate and verifiable instead.

Get practical security analysis like this delivered to your inbox. Subscribe to CyberDesserts for working developer and security team insights, no fluff.

What is npm security in 2026

npm is the largest software registry in the world. According to Sonatype's 2026 State of the Software Supply Chain report, 2025 saw 9.8 trillion downloads across Maven Central, PyPI, npm, and NuGet combined. The same report identifies 454,648 new malicious packages discovered in 2025 alone.

The scale is the threat surface. Every developer reading this is downstream of every other developer's dependency decisions. A modern Node.js project pulls hundreds of transitive dependencies, most of them maintained by individuals or small teams the consuming developer has never met.

That is the dependency tree, and it has been the implicit trust surface of software for fifteen years. What changed in 2025-2026 is not the existence of the supply chain. What changed is the threat model.

Attackers are no longer looking for vulnerabilities in popular packages. They are compromising the trust relationships that make the supply chain possible at all: the registry's signing infrastructure, the maintainer's credentials, and the developer's habit of running npm install without reading the code.

The trust-flow exploit pattern is not theoretical. We have documented this pattern across multiple npm supply chain attacks at CyberDesserts in the last year, from individual maintainer compromises like axios to four generations of the self-replicating Shai-Hulud worm. Each generation has been more sophisticated than the last.

Across the 2025-2026 npm incident wave, the attack pattern is consistently a trust-flow exploit, not a tooling failure, which means npm security in 2026 is an explicit-trust workflow problem first.

The npm supply chain incident wave: Shai-Hulud and what came after

What started as a credential-harvesting compromise in September 2025 has, by May 2026, become a cross-registry attack that subverts the very mechanisms designed to prevent supply chain attacks.

Shai-Hulud (September 2025)

Shai-Hulud is a self-replicating npm worm first disclosed by Palo Alto Networks Unit 42 in September 2025. The initial wave compromised approximately 500 npm packages through a worm that ran in the post-install script of each compromised package, harvesting credentials and self-propagating into any package the victim could publish to.

The payload was credential theft from .npmrc, .aws/credentials, GitHub tokens, and other authentication artifacts on the compromised developer machine. The exfiltration was to public GitHub repositories with the descriptor "Shai-Hulud."

The novel aspect at the time was the self-replication. Most prior supply chain attacks required a separate exploitation per package; Shai-Hulud automated the propagation. For deeper analysis of how maintainer accounts get compromised in these attacks, see the npm supply chain maintainer attacks reference and the axios npm supply chain attack case study.

Shai-Hulud 2.0 (November 2025)

On 25 November 2025, Datadog Security Labs and Microsoft Security Research disclosed a significant evolution of the campaign, tracked as Shai-Hulud 2.0. The new version compromised 796 unique npm packages across 1,092 unique versions.

Two technical changes stood out. Shai-Hulud 2.0 installed the Bun JavaScript runtime on infected machines, likely to evade EDR products tuned to monitor Node.js processes. It also added a GitHub self-install worker, allowing the attacker to use GitHub-native features for remote code execution on compromised machines.

The exfiltration targets were public GitHub repositories with the description "Sha1-Hulud: The Second Coming." The campaign automatically backdoored up to 100 packages per compromised maintainer account, hitting widely used packages from Zapier, PostHog, and Postman.

Shai-Hulud: The Third Coming (April 22, 2026)

Generation three arrived on 22 April 2026, attributed by Palo Alto Unit 42 to the TeamPCP threat actor. The campaign moved beyond pure maintainer compromise into weaponising compromised developer-tooling distribution channels, deploying the same payload across multiple security-tool packages simultaneously.

The campaign's defining moves included impersonation of legitimate security tools and compromise of vendor distribution channels. A malicious package published as @bitwarden/cli@2026.4.0 was briefly distributed through the npm delivery path between 5:57 PM and 7:30 PM EST on 22 April 2026 before Bitwarden's security team identified and contained it. Checkmarx distribution channels were used to deliver the same payload through compromised developer-tooling credentials, indicating a coordinated effort to maximise blast radius.

The exfiltration targets were public GitHub repositories with the descriptor "Shai-Hulud: The Third Coming." Where Shai-Hulud 2.0 cascaded through maintainer-account compromises, Third Coming weaponised the developer's trust in security tools themselves. The trust-flow exploit moved into a new layer.

Mini Shai-Hulud (April-May 2026, ongoing)

On 11 May 2026, Microsoft Security Research identified what the campaign's operators call Mini Shai-Hulud, with first signs visible in late April 2026. Microsoft's disclosure puts the count at 170+ npm packages and 404 versions, with 2 PyPI packages also affected, making it the first supply chain attack to span both registries in a single coordinated operation. Counts from other researchers vary between 169 and 373 versions depending on what they include and when they sampled, which is itself a tell about how live the campaign is at the time of writing.

The first wave in late April targeted the SAP developer ecosystem with malicious versions of @cap-js/sqlite, @cap-js/postgres, and @cap-js/db-service. The escalation through May has hit major brands: TanStack, Mistral AI, Zapier, PostHog, and Postman maintainer accounts have been compromised, and packages those maintainers control have been republished with malicious versions.

The mechanism is the most consequential part. Mini Shai-Hulud subverts npm's Trusted Publishing infrastructure: short-lived OIDC tokens issued by GitHub Actions are hijacked from CI/CD runners, then used to publish malicious versions with valid SLSA Build Level 3 provenance attached.

The malicious packages look authentic to scanners and registries because the cryptographic signatures are valid. The attacker is the legitimate publisher at the moment of publication. Sonatype's analysis records over 1.2 million malicious packages blocked across the open source ecosystem in 2025; Mini Shai-Hulud is the design pattern those blocks are trying to anticipate.

The "trust-flow exploit" pattern

Across all four Shai-Hulud generations, the attack is consistent on the layer it exploits, even as the technical implementation evolves. None of these attacks rely on a vulnerability in a package. They rely on the trust developers and registries place in each other.

Trust in the registry. SLSA provenance and Trusted Publishing were designed to be the cryptographic foundation of supply chain trust. Mini Shai-Hulud demonstrates that when the registry trusts a Build Level 3 signature, the attacker who has captured the OIDC token gets the same trust.

Trust in the maintainer. Phished or stolen credentials at Zapier, PostHog, Postman, TanStack, Mistral AI, and dozens more turn the maintainer into an unwitting attacker without their knowledge.

Trust in the dependency tree. Every modern project trusts that the resolved version of every transitive dependency is the one its author intended. A maintainer compromise at any layer breaks that assumption silently.

A vulnerability scanner reading the CVE feed will never see any of this. There is no CVE for a maintainer whose npm 2FA token got phished. There is no advisory for an OIDC token that was hijacked from a GitHub Actions runner.

The maintainer's account was never vulnerable; it was compromised. The dependency was never vulnerable; it was hijacked. The package published from a compromised CI/CD runner has cryptographically valid provenance because the attacker captured the legitimate publishing credential.

The defence is not a better scanner, it is a workflow that does not assume any of these trust relationships hold by default.

Why npm audit doesn't catch supply chain attacks

Can npm audit detect a supply chain attack? Not the kind that compromises trust rather than introducing a vulnerability.

What it does well is identify packages in the dependency tree with known CVEs documented in npm's advisory database. That coverage matters and should not be discarded. It is the wrong tool for the trust-flow exploit class, however, because supply chain attacks of the kind documented above are structurally different from the vulnerabilities npm audit is designed to find.

A maintainer compromise turns the maintainer into the malicious agent. The package itself remains technically legitimate; the new version simply contains hostile code that the audit cannot recognise as malicious because no advisory documents it yet.

A trust-flow exploit attacks the registry's signing infrastructure, the maintainer's credentials, or the dependency tree's resolution logic. None of those are package vulnerabilities. npm audit is not designed to detect them, and shipping faster checks against an outdated advisory does not change that.

A coverage gap matters: Sonatype's 2026 State of the Software Supply Chain report identifies 65% of all OSS CVEs lacking NVD scores in 2025, leaving the largest data-driven defence the ecosystem has incomplete by design.

Sonatype's enriched analysis brings the actionable CVSS coverage from 35% to 91% by adding their own enrichment to the NVD data. The same report finds 28.6% of OSS components in modern applications are out of date, and that 80% of vulnerabilities discoverable by the existing scanning tooling are remediable, the bottleneck being workflow rather than detection.

The result is npm audit is necessary but not sufficient. The supply chain attacks of 2025-2026 demand a different category of defence. For deeper coverage of the audit limitations, see npm audit fix not working.

npm security tools: scanners, registries, and what each actually catches

The npm security tool landscape splits into three categories: scanners for known CVEs, behavioural scanners for malicious code patterns, and registry-level controls that intervene before installation.

npm audit is npm's built-in CVE scanner. Useful for the CVE class; misses supply chain attacks for the structural reasons above.

Snyk and Socket are behavioural scanners that catch malicious package patterns: suspicious post-install scripts, unusual network activity, obfuscated code, sudden behavioural changes in a previously stable package. Both ran early detection on portions of the Shai-Hulud campaign series. For comparison across npm scanners, see the npm vulnerability scanner reference.

Dependabot and Renovate automate dependency updates with awareness of the npm advisory feed. They do not detect supply chain attacks themselves but are essential for the explicit-trust workflow because they make it sustainable to pin versions strictly while keeping pace with legitimate updates.

Sonatype Repository Firewall (and Nexus Lifecycle) operate at the enterprise level, blocking malicious packages before download into the build environment based on Sonatype's continuous research into open source malware. Sonatype themselves recommend the firewall as the primary control against the Shai-Hulud campaign series. For current vulnerable packages and CVE-specific guidance, see the npm security vulnerabilities reference.

SBOM tooling sits alongside the scanners as a visibility layer rather than a detection layer. Software Bills of Materials make the dependency tree auditable so that other tools have something concrete to act on. The depth coverage on SBOM generation and consumption lives in the supply chain auditing spoke.

The honest assessment from twenty years of watching teams buy security tooling: no single tool catches the trust-flow exploit class on its own. The vendor pitch says one tool covers the whole problem; the reality is that each category handles one layer of the trust chain, and the defence has to be layered, automated, and inline. That is the workflow.

The explicit-trust workflow: securing npm in practice

What is the most secure way to use npm in 2026? The same answer as any other modern engineering challenge: automation that runs at the speed the team ships, with five steps wired into the pipeline.

1. Lockfile and pinning discipline. package-lock.json is committed and treated as a source artifact. CI fails on lockfile drift. Production builds use npm ci, not npm install, so the resolved dependency tree is exactly the one that was reviewed.

Version ranges in package.json sit upstream of the lockfile and deserve the same deliberateness. npm's default caret notation (^1.7.2) permits any minor or patch update at the next install, which is precisely the surface a maintainer compromise exploits when a malicious patch ships under the legitimate maintainer's account. Strict pinning to 1.7.2 exactly removes that surface.

The trade-off is real. Strict pinning without an automated update flow is worse than ranged versioning with monitoring, because it leaves teams on vulnerable versions for months when the update mechanism that was removed is never replaced. The modern resolution is strict pinning combined with Renovate or Dependabot proposing updates as pull requests, so the team reviews the decision to update rather than discovering an updated dependency at the next CI run.

This is why version pinning is widely under-adopted: teams reach for the technique without the automation that makes it sustainable.

2. Inline dependency review at install time. Behavioural scanner (Socket or equivalent) running automatically in the install path. Detected anomalies halt the install and surface developer-facing context, not a generic security block. The automation is the point: the developer keeps shipping, the malicious package does not.

3. Continuous supply chain monitoring. Sonatype Repository Firewall, Snyk runtime, or equivalent, watching the registry trust layer in production. The same tooling that catches the CVE feed should be watching for the unsigned republished version of a package that arrived in your fleet yesterday.

4. Maintainer change alerts. Judging from the blast radius of recent maintainer compromises, tracking when a maintainer changes on a critical dependency appears to be widely under-adopted in practice. This is the canary for the trust-flow exploit class. Tools like Socket, Snyk, and Sonatype provide this signal; the workflow change is to act on it rather than treat it as background noise.

5. Incident response readiness. A documented runbook for "we were affected by a supply chain attack." Token rotation steps, lockfile audit against known indicators of compromise, CI/CD credential review.

How do you check if your project is affected by a supply chain attack? Audit your lockfile against the campaign's IoC list, rotate every credential that touched the build environment during the exposure window, and walk the dependency tree backward from the compromised package to identify every consumer that pulled the malicious version. The Shai-Hulud campaigns prove this is now a routine engineering activity, not a tabletop exercise.

For deeper coverage on the auditing step, see the supply chain auditing workflow.

The workflow's character is the point as much as its content. Each step is automated, inline, and runs at pipeline speed.

None of them require a security ticket. None of them require a developer to wait. The discipline of building this kind of pipeline is the DevSecOps role.

npm security as continuous threat exposure management

npm security as a workflow problem maps cleanly to the Continuous Threat Exposure Management framework. Scope, discover, prioritise, validate, mobilise.

The package registry is the scope. Discovery is the SBOM and dependency tree work. Prioritisation is which dependencies are critical enough to monitor with maintainer-change alerts. Validation is the inline scanning and incident response readiness. Mobilisation is the automated CI/CD pipeline that operationalises everything else.

The pipeline automation is what makes this CTEM rather than a series of point-in-time scans. Scope, discover, prioritise, validate, and mobilise are continuous loops, not annual exercises.

The 2025 Gartner supply chain prediction (which we revisited in detail recently) was that 45% of organisations globally would experience supply chain attacks by 2025. The number matters less than the trajectory, which the four Shai-Hulud generations and Mini Shai-Hulud cross-registry attack confirm.

CTEM as a discipline gives security leaders a frame for the workflow described above without requiring them to learn npm internals. For the full framework, see what is CTEM.

In DevSecOps-mature organisations, the workflow described above is in place because the role exists. In organisations still running periodic audits and weekly security reviews, the workflow isn't in place because the role isn't either. The labour market is telling us which orientation organisations are choosing: DevSecOps appears in the April 2026 cybersecurity career report as the highest-velocity emerging role of 2026, with hiring growth that tracks the supply chain attack curve.

Where npm security is heading: provenance, sigstore, and the next wave

The package registry is improving its defences. provenance via sigstore is now functional, Trusted Publishing reduces the attack surface for credential theft, and the publisher-side authentication overhaul completed in December 2025 has measurably reduced the credential-stuffing class of attacks.

The maintainer's account is still the weak link. As demonstrated by Mini Shai-Hulud subverting Trusted Publishing through OIDC token theft, every registry-level protection assumes the publisher's credential has not been hijacked. When that assumption breaks, the protection breaks with it.

The defence is an explicit-trust workflow at the developer's side, where the cryptographic verification of provenance is paired with behavioural verification of what the package does at install time. The registry-side improvements are necessary infrastructure; they cannot stand alone as a defence. The argument is that registry-layer protections are necessary but cannot be sufficient on their own. Developer-side explicit-trust workflow is the only durable response.

The trend reading: the next wave targets the AI-assisted development layer specifically. Model poisoning, prompt injection in dependency suggestion, and AI agents that auto-merge dependency updates without human review are the natural extension of the trust-flow exploit pattern. The framing extends without modification.

Role demand echoes the threat model. DevSecOps as the fastest-growing emerging role in 2026 is the labour-market signal that organisations have read the same trend. The role exists because the threat model has changed; the defensive response has to operate at the same speed and on the same surfaces as the attack.

Summary

npm security in 2026 is an explicit-trust workflow problem first, a tooling problem second. The Shai-Hulud campaign series proves the trust layer is the attack surface, not the package layer. The defence is the DevSecOps discipline applied to npm: automated controls in the CI/CD pipeline scaling with shipping velocity, not periodic scans.

The next wave is not hypothetical. Mini Shai-Hulud is active as of May 2026, and the registry-level defences it subverts were the strongest controls the ecosystem had.

The supply chain audit walkthrough is where the workflow above gets tested against a real dependency tree. The question for every team running npm in production is not whether the next trust-flow exploit lands, but whether the answer is already in place.

This guide gets refreshed when major changes hit the npm security landscape. Subscribers get the heads-up when the next Shai-Hulud generation lands, plus weekly practical security analysis. No sales pitches, no fluff.