npm Supply Chain Attacks in 2026: What SaaS Engineering Teams Must Know

npm supply chain attacks hit critical mass in 2025. The JavaScript ecosystem saw its most devastating year: self-replicating worms, zero-day vulnerabilities in package managers themselves, and hijacked packages with billions of weekly downloads. For SaaS engineering teams, "just run npm audit" is no longer adequate.

This guide covers the major incidents of 2025-2026, the attack techniques you need to understand, and practical defenses that go beyond the basics. We also address what your SOC 2 auditor expects when it comes to third-party risk management.

The 2025-2026 Attack Landscape

Shai-Hulud: The Self-Replicating npm Worm

The Shai-Hulud campaigns represent the most sophisticated npm attacks to date. Named after the sandworms of Dune, this malware spread autonomously through the ecosystem in two major waves.

Shai-Hulud 1.0 (September 2025) compromised over 500 packages through stolen maintainer credentials. The malware scanned infected environments for GitHub Personal Access Tokens and cloud API keys (AWS, GCP, Azure), uploading harvested credentials to a public repository. It then used victim npm credentials to inject code into additional packages, creating exponential spread.

Shai-Hulud 2.0 (November 2025) evolved significantly. According to Datadog Security Labs, this variant compromised 796 unique packages with over 20 million weekly downloads. Key innovations included:

• Installing the Bun runtime to evade Node.js monitoring
• Injecting malicious setup_bun.js and bun_environment.js files via preinstall scripts
• Exfiltrating credentials through public GitHub repositories
• A "dead man's switch" threatening data destruction if exfiltration channels were severed
• Automatic propagation to up to 100 packages per infected maintainer account

The worm's efficiency was alarming: a single compromised developer could inadvertently infect their entire package portfolio within minutes.

September 2025: 18 Packages, 2 Billion Weekly Downloads

In September 2025, attackers hijacked 18 popular npm packages including debug and chalk, libraries present in virtually every Node.js project. With combined downloads exceeding 2.6 billion per week, this was one of the largest npm attacks in history.

The attack vector was social engineering: maintainers received convincing 2FA reset emails from a fake domain (npmjs.help), surrendering their credentials. The injected malware targeted cryptocurrency wallets and blockchain transactions.

PackageGate: Zero-Days in the Package Managers Themselves

In January 2026, security researchers at Koi disclosed six zero-day vulnerabilities affecting npm, pnpm, vlt, and Bun. Dubbed "PackageGate," these flaws undermined the primary defenses recommended after Shai-Hulud: disabling lifecycle scripts and relying on lockfiles.

The most concerning issue involves Git-based dependencies. A repository can carry configuration that influences how the package manager performs Git operations during install, enabling code execution even when lifecycle scripts are supposedly blocked.

pnpm, vlt, and Bun resolved the issues within weeks. npm closed the report as "informative," stating the feature works as intended, a response that left many in the security community concerned.

npx Confusion: 128 Unclaimed Package Names

Aikido Security's research revealed a different attack vector: official documentation instructing developers to run packages via npx that were never actually published to npm.

The researchers found and claimed 128 unclaimed package names referenced in official READMEs and documentation. Seven months later, these packages had received 121,000 downloads. Every single download would have executed arbitrary code.

Major at-risk packages included openapi-generator-cli, cucumber-js, and depcruise, each with 10,000+ potential malicious downloads. The attack is trivially simple: register the unclaimed name, add a preinstall script that exfiltrates environment variables.

npm's Security Response

npm and GitHub have implemented significant security hardening in response to these attacks.

December 2025: The Authentication Overhaul

Following the Shai-Hulud incidents, npm completed a major authentication overhaul:

• Classic tokens deprecated: All legacy tokens were revoked
• Granular Access Tokens: Required for all publishing, with shorter expiration (7 days for publishing permissions)
• TOTP 2FA deprecated: FIDO-based 2FA (hardware keys, passkeys) now required
• Publishing access defaults: Tokens cannot publish by default; explicit scope required
• Trusted Publishing: OIDC-based publishing from GitHub Actions, eliminating stored credentials

These changes directly address the credential theft that enabled Shai-Hulud's spread. However, they require action from package maintainers: legacy authentication methods no longer work.

Provenance Attestation

npm now supports provenance attestation, allowing packages to cryptographically prove they were built from a specific Git commit through a verified CI/CD pipeline. When viewing a package on npm, you can verify:

• The source repository
• The commit that produced the build
• The CI/CD workflow that published it

Packages with provenance show a green checkmark on npm. While not yet widely adopted, provenance will become increasingly important for supply chain verification.

Practical Defenses for SaaS Teams

1. Lock Your Dependencies

Lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) pin exact versions and include integrity hashes. Every install verifies that downloaded packages match the expected cryptographic hash.

Critical practices:

• Always commit lockfiles to version control
• Use npm ci in CI/CD, not npm install (it respects the lockfile exactly)
• Review lockfile changes in pull requests; they can indicate dependency tampering
• Enable integrity checking (default in npm 7+, verify integrity fields exist in lockfile)

The PackageGate research showed lockfiles aren't a complete defense against Git-based dependencies, but they remain essential for registry packages.

2. Disable Lifecycle Scripts

Lifecycle scripts (preinstall, postinstall, prepare) are the primary malware execution vector. Both Shai-Hulud variants relied on preinstall scripts.

Options:

1# npm: ignore scripts globally
2npm config set ignore-scripts true
3
4# Per-project in .npmrc
5ignore-scripts=true
6
7# Allow specific packages (npm 9+)
8# In package.json
9"overrides": {
10  "esbuild": {
11    "scripts": true
12  }
13}

Consider using Datadog's Supply Chain Security Firewall (SCFW), which can block known malicious packages at install time.

3. Audit and Monitor Dependencies

npm audit catches known vulnerabilities but misses zero-days and malicious packages without CVEs. Layer additional tools:

• Socket.dev: Detects suspicious package behavior (network access, filesystem access, obfuscated code)
• Snyk: Continuous monitoring with fix PRs
• Dependabot: Automated security updates
• Aikido Safe Chain: Blocks malicious packages in real-time

Run audits in CI/CD pipelines and fail builds on high-severity issues.

4. Implement a Dependency Cooldown

A 7-14 day waiting period before adopting new packages or major updates would have prevented most 2025 attacks. Malicious packages are typically detected within days.

Practical approach:

• Pin to specific versions, not ranges (1.2.3, not ^1.2.3)
• Evaluate new dependencies before adding them (check maintainers, recent activity, download patterns)
• Delay updates to give the community time to detect issues
• Subscribe to security advisories for critical dependencies

5. Generate and Review SBOMs

A Software Bill of Materials (SBOM) inventories every component in your application. CISA's 2025 guidance requires machine-readable formats (SPDX or CycloneDX).

Generate SBOMs in your build pipeline:

1# Using npm (basic)
2npm sbom --sbom-format cyclonedx
3
4# Using Syft (comprehensive)
5syft . -o cyclonedx-json > sbom.json

SBOMs enable rapid response when vulnerabilities emerge. When the next Shai-Hulud hits, you'll know within minutes if you're affected.

6. Verify Provenance

For critical dependencies, verify provenance attestation:

1npm audit signatures

Prefer packages published with Trusted Publishing (look for the provenance badge on npm). This ensures the package came from verified CI/CD, not a compromised developer laptop.

7. Secure Your CI/CD Pipeline

CI/CD pipelines are prime targets. The s1ngularity attack exploited GitHub Actions' pull_request_target trigger to steal npm publishing tokens.

Hardening measures:

• Never use pull_request_target with untrusted code checkout
• Rotate npm tokens regularly; use short-lived tokens where possible
• Store secrets in dedicated secret managers, not environment variables
• Audit GitHub Actions workflows for excessive permissions
• Enable branch protection and require reviews for workflow changes

SOC 2 and Third-Party Risk Management

Supply chain security isn't just a technical concern. SOC 2 auditors expect documented controls for vendor and third-party risk management.

CC9.2: Risk from Vendors and Business Partners

The CC9.2 criterion directly addresses third-party risk. For software dependencies, auditors expect:

• Inventory: A complete list of dependencies and their sources
• Risk assessment: Evaluation of critical dependencies' security posture
• Ongoing monitoring: Continuous vulnerability scanning and alerting
• Incident response: Procedures for responding to compromised dependencies

An SBOM addresses the inventory requirement. Automated scanning tools demonstrate ongoing monitoring. Documented runbooks show you have incident response procedures.

Continuous Oversight, Not Point-in-Time

SOC 2 Type II requires demonstrating controls operated effectively over the audit period. Point-in-time assessments are insufficient. Auditors expect:

• Regular dependency audits (automated in CI/CD)
• Evidence of vulnerability remediation
• Documentation of security decisions (why you accepted certain risks)
• Response records when incidents occurred

If your organization experienced a dependency-related incident, auditors will want to see how you detected it, responded, and prevented recurrence.

Documentation Requirements

Maintain documentation covering:

1. Dependency management policy: How you evaluate, approve, and monitor dependencies
2. Vulnerability management procedures: SLAs for patching based on severity
3. Incident response playbook: Steps for responding to compromised packages
4. Risk register: Known risks from dependencies and compensating controls

Bastion's compliance platform includes built-in dependency scanning and supply chain monitoring, generating the evidence auditors need without manual effort.

Conclusion

The npm ecosystem faced unprecedented attacks in 2025. Self-replicating worms, zero-days in package managers, and social engineering campaigns demonstrated that supply chain security requires defense in depth.

For SaaS engineering teams, the path forward includes:

1. Lock and verify: Commit lockfiles, use npm ci, verify integrity
2. Minimize attack surface: Disable lifecycle scripts, audit dependencies
3. Monitor continuously: Automated scanning in CI/CD, real-time blocking
4. Document for compliance: SBOMs, risk assessments, incident procedures

npm's authentication overhaul and provenance attestation provide better foundations, but they require adoption. The ecosystem is only as secure as its weakest maintainer account.

Supply chain attacks will continue evolving. The question isn't whether your dependencies will be targeted, but whether you'll detect it when they are.

Bastion helps SaaS companies achieve SOC 2 and ISO 27001 certification with built-in security tools, including dependency scanning and supply chain monitoring. Learn more about our approach to compliance.