Poisoned Packages: Auditing the NPM Supply Chain

The Attack That Targeted the Supply Chain

The npm ecosystem faced what security researchers call a watershed moment in September 2025 when a self-replicating worm, dubbed "Shai-Hulud," compromised over 500 packages. Named after the massive sandworms from Frank Herbert's Dune that could destroy entire cities, this digital worm lived up to its namesake, automatically spreading through the ecosystem.

Palo Alto Networks Unit 42 confirms it represents "a significant evolution in supply chain threats," marking a fundamental shift from manual credential theft to automated, exponential propagation.

How Self-Propagating Worms Work

Unlike traditional supply chain attacks requiring manual intervention, these worms operate autonomously:

1. Harvest credentials - Scan for GitHub tokens, npm credentials, and cloud API keys
2. Exfiltrate data - Send stolen secrets to attacker-controlled endpoints
3. Self-propagate - Use harvested credentials to publish malicious versions of other packages
4. Repeat - Create exponential spread across the ecosystem

According to Unit 42, the worm executes during post-install scripts, automatically seeking and infecting additional packages the compromised maintainer controls. CISA confirmed the malware "leveraged an automated process to rapidly spread by authenticating to the npm registry as the compromised developer, injecting code into other packages, and publishing compromised versions to the registry."

The Shai-Hulud worm followed another major attack. A week earlier on September 8th, attackers compromised packages like debug (47 million weekly downloads) and chalk (299 million weekly downloads) through phishing, affecting approximately 10% of cloud environments within two hours. These incidents demonstrate the escalating nature of npm supply chain attacks.

Detecting Poisoned Packages

Traditional npm audit only catches known vulnerabilities after they're reported. For emerging threats, organisations need continuous validation across multiple indicators.

Key Warning Signals:

Package Behaviour:

• Unexpected version releases from maintainers with irregular publishing patterns
• Post-install scripts appearing in previously script-free packages
• Obfuscated code in JavaScript files
• Network requests to unfamiliar domains during installation

Environmental Indicators:

• Unauthorised GitHub repositories under developer accounts
• Suspicious GitHub Actions workflows added to repositories
• Cloud API keys appearing in public repositories

For comprehensive detection beyond npm's built-in tools, building a custom npm vulnerability scanner that queries multiple vulnerability databases provides broader coverage. The scanner leverages the deps.dev API to track package age, maintenance status, and vulnerabilities from sources npm audit might miss.

Key Takeaways

The attacks fundamentally changed the npm threat landscape:

• Self-replicating worms can compromise hundreds of packages within hours
• Even popular packages with billions of downloads are vulnerable to account compromise
• Point-in-time security scans are insufficient against rapidly evolving threats
• Continuous validation across multiple data sources is essential
• Layered defenses combining detection, process controls, and runtime protection are critical

The Bottom Line

A single phishing email cascaded into 500+ compromised packages affecting billions of downloads. Organisations can no longer assume popular packages are inherently safe or that npm's built-in security is sufficient.

Having the visibility and processes to detect poisoned packages before they reach production is key.

How effective is your approach to npm supply chain vulnerabilities ?

Resources:

• CISA Alert: Widespread Supply Chain Compromise
• Palo Alto Unit 42: Self-Replicating Worm Analysis
• Building a Custom NPM Vulnerability Scanner