Multi-Wave npm Supply Chain Attacks — IronWorm, Phantom Gyp, and the Erosion of Trust

In June 2026, the JavaScript ecosystem experienced one of its most severe security crises: a coordinated wave of supply chain attacks across npm that compromised developers’ credentials, stolen API keys from major AI companies, and laid bare the fragility of trust in package management infrastructure.

This wasn’t a single attack. It was a multi-front assault—four distinct worms operating in parallel, each exploiting different vulnerability vectors, collectively affecting hundreds of packages and exposing millions of developers to credential theft. The sophistication and coordination suggest professional threat actors with deep knowledge of npm’s ecosystem and developer workflows. This attack follows the same pattern of trust exploitation we’ve seen in previous npm supply chain incidents, but with dramatically increased sophistication and coordination.

The Four Worms: A Coordinated Attack

#

IronWorm: Rust-Based Information Stealer

#

Timeline: June 3-15, 2026
Affected Packages: 37+ npm packages
Attack Vector: Direct malicious code injection

IronWorm represents a new paradigm in npm attacks: a sophisticated information stealer written in Rust, compiled to WebAssembly, and distributed across the npm ecosystem. This attack focused on exfiltrating valuable data:

• Credential Targets:

  • SSH keys from ~/.ssh/
  • Git credentials from .git/config
  • Docker credentials from ~/.docker/
  • AWS credentials from ~/.aws/
  • Environment variables containing API keys (the most dangerous form of secret storage)

• Affected Packages:

  • Popular development utilities
  • Build tool dependencies
  • CLI helpers widely used in CI/CD pipelines

• Exfiltration Method: Data was sent to attacker-controlled servers during package installation, often masked as legitimate npm registry requests

The Rust/WASM approach is particularly concerning because it’s:

• Platform-independent: Works across Windows, macOS, Linux
• Harder to analyze: Binary format makes code inspection difficult
• Performance-optimized: Minimal overhead, reducing detection probability

Phantom Gyp: The Bypass Exploit

#

Timeline: June 3-15, 2026
Affected Packages: 57 packages
Malicious Versions: 286+ versions
Attack Vector: Bypassing npm install --ignore-scripts protections

Phantom Gyp’s sophistication lies in its evasion technique. For years, developers have protected themselves using:

npm install --ignore-scripts

This flag prevents lifecycle scripts (preinstall, postinstall, build) from executing during package installation. Phantom Gyp bypassed this fundamental protection by exploiting how Node.js processes optional dependencies. This same pattern of defensive measures being circumvented is what makes each successive attack more dangerous than the last.

The Attack Flow:

1. Main package declares optional dependency on a “build helper”
2. When npm install --ignore-scripts runs, optional dependencies are still processed
3. Optional dependency’s package.json triggers scripts that execute regardless of --ignore-scripts flag
4. Attacker code runs with full filesystem access, installs backdoors, exfiltrates data

What Made This Critical:

• Even security-conscious developers using --ignore-scripts were vulnerable
• The attack exploited Node.js dependency resolution logic, not npm bugs
• Organizations running hardened CI/CD pipelines with script protections still got compromised

Miasma: The Persistence Layer

#

Timeline: June 3-15, 2026
Attack Vector: Long-term persistence and lateral movement

Miasma’s role was establishing long-term foothold. Once other worms exfiltrated credentials, Miasma:

• Created reverse shells for remote access
• Installed persistence mechanisms in project node_modules/.bin/
• Hooked into npm lifecycle to reinstall itself after updates
• Modified .npmrc files to redirect package installations to attacker servers

This created a lasting compromise where developers couldn’t simply update—the persistence mechanisms would reinstall the backdoor.

Shai-Hulud: The Propagation Engine

#

Timeline: June 3-15, 2026
Role: Worm self-replication and horizontal spread

Named after the sandworms of Dune, Shai-Hulud automated propagation across the ecosystem:

• Scanned node_modules for other developers’ projects
• Injected malicious code into local packages
• Attempted to publish compromised versions to npm registry
• Modified git repositories to commit backdoored code

This created an ecosystem-wide contagion effect where a single developer’s machine could compromise hundreds of downstream dependencies.

The Scale of Compromise

#

Affected Developers

#

• Direct installations: Thousands of developers directly installed compromised packages
• Transitive dependencies: Millions more through downstream dependencies
• CI/CD pipelines: Hundreds of organizations ran malicious code in production builds
• Credentials exposed:
  • Anthropic API keys: 47,000+ stolen credentials
  • OpenAI API keys: 23,000+ stolen credentials
  • GitHub tokens: 89,000+ exposed
  • AWS credentials: 156,000+ compromised

Attack Effectiveness

#

The timing was no accident. These attacks occurred during:

• Developer busy season: Q2 finalization, increased deployment activity
• Build system updates: New releases made attack packages appear as security updates
• Open source trust: Developers assume npm packages are vetted after reaching mainstream usage

Why Current Safeguards Failed

#

1. The Trust Paradox

#

npm registry trusts that published code matches source repositories. But attackers only need to compromise:

• A developer account
• A maintainer’s credentials
• An abandoned but maintained package

Once in, they can publish malicious updates to “stable” versions that existing projects will automatically install.

2. The Script Execution Problem

#

JavaScript ecosystem’s reliance on lifecycle scripts (preinstall, postinstall, build) provides attackers with code execution during installation. This is by design—it enables build systems, native module compilation, and dependency setup. But it’s also the front door for supply chain attacks.

Solutions exist:

• npm install --ignore-scripts (now proven insufficient)
• npm audit (only detects known vulnerabilities, not malware)
• npm sbom (software bill of materials)

But they’re opt-in and imperfect.

3. The Dependency Resolution Blindness

#

Most developers don’t audit transitive dependencies. You may trust a package you directly depend on, but you don’t audit all of its dependencies. Phantom Gyp exploited this by attacking packages deep in the dependency tree where they’d never be noticed until damage was done.

4. The Credential Proliferation Problem

#

Modern development requires numerous credentials:

• Cloud provider credentials (AWS, Azure, GCP)
• API keys (OpenAI, Anthropic, GitHub)
• SSH keys for deployment
• Docker registry credentials

Most developers store all of these in standard locations (~/.ssh/, ~/.aws/, environment variables). A single compromised package gains access to everything.

Immediate Response: What Developers Must Do

#

1. Credential Rotation (URGENT)

#

If you installed any npm packages between June 3-15, 2026:

Rotate immediately:

# AWS
aws iam create-access-key
aws iam delete-access-key --access-key-id <old-key>

# GitHub
# Settings → Developer Settings → Personal Access Tokens → Regenerate

# OpenAI/Anthropic API Keys
# Regenerate via console

# SSH Keys
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
# Update authorized_keys on all servers

2. Audit Your Projects

#

Use npm audit and SBOM tools to analyze your dependencies:

# Check your node_modules for suspicious packages
npm list --all | grep -E "ironworm|phantom|miasma|shai"

# Check installed packages from the attack window
npm list --json > /tmp/npm-tree.json
# Review /tmp/npm-tree.json for unfamiliar packages

# Check git history for unexpected commits
git log --all --oneline | head -20

3. Verify Your Supply Chain

#

Implement supply chain security best practices through tooling:

# Use npm ci (clean install) instead of npm install
npm ci --ignore-scripts

# Generate SBOM
npm sbom --output cyclonedx

# Check for known compromised packages
npm audit --audit-level=moderate

4. Update .npmrc with Protections

#

Harden your npm configuration to prevent script execution:

# ~/.npmrc
ignore-scripts=true
audit=true
fund=false
scripts-warn-on-use=true

5. Check CI/CD Logs

#

If your build pipelines ran during this window, review:

• Build logs for suspicious commands
• Network egress logs for unexpected API calls
• Git history for unauthorized commits
• Container image registries for backdoored deployments

Broader Implications: The Trust Crisis

#

For Organizations

#

1. Dependency Management Becomes Critical - You can’t rely on “trusting” packages. Implement:

   • Software Composition Analysis (SCA) tools
   • Network isolation for build systems
   • Credential segregation by environment

2. Supply Chain Security Is Now Table Stakes - CISA, NSF, and major tech companies are pushing for:

   • Package signing standards
   • Provenance metadata
   • Build system transparency

3. Open Source Sustainability Crisis Deepens - Maintainers are exhausted. Without resources for security, attacks like this will repeat.

For Package Managers

#

npm’s response includes:

• Increased abuse team resources
• Stricter account recovery procedures
• Mandatory two-factor authentication for publishing
• Package signing support in npm 10.0+

But these are band-aids on a structural problem.

For the Industry

#

The JavaScript ecosystem is facing a reckoning:

1. Runtime Code Execution on Install - Languages with package managers that don’t execute arbitrary code during installation (Rust’s Cargo, Go’s modules) have cleaner security models

2. Cryptographic Verification - Package signatures, build provenance, and attestations are becoming essential infrastructure, not nice-to-haves

3. Developer Education - Most developers don’t understand supply chain risks. Security needs to be built-in, not bolted-on

Long-Term Mitigation Strategies

#

For Developers

#

• Principle of Least Privilege: Use separate credentials for different contexts
• Automated Dependency Updates: Use tools like Dependabot with automated testing
• Provenance Verification: Validate package signatures when available
• Network Segmentation: Isolate build systems from production credentials

These strategies are part of a broader supply chain security framework that organizations need to implement systematically.

For Organizations

#

• Zero Trust for Dependencies: Assume packages may be compromised; monitor behavior
• Build System Hardening: Separate build credentials from deployment credentials
• Artifact Attestation: Verify that artifacts were built from expected source code
• Incident Response Planning: Develop playbooks for supply chain compromises

For the Ecosystem

#

• Package Signing Standards: Move npm registry to require cryptographic verification
• Provenance Metadata: Standardize how package origins are documented
• Build Transparency: Make it possible to verify what code runs during installation
• Maintainer Support: Fund full-time security for critical packages

My Take

#

IronWorm, Phantom Gyp, Miasma, and Shai-Hulud represent a sophisticated evolution in supply chain attacks. They weren’t opportunistic exploits of known vulnerabilities—they were targeted, coordinated operations exploiting design decisions in the Node.js ecosystem.

The good news: developers can take immediate steps to detect and remediate compromises.

The concerning news: fundamental structural problems in how JavaScript packages are executed and distributed require ecosystem-wide changes that will take years to implement.

The critical insight: in a world where malicious packages can execute arbitrary code during installation with access to your credentials, “trusting” packages is insufficient. Security must be enforced technically, not socially.

If you use npm, this attack happened on your machine. Treat it as a security incident. Rotate your credentials. Audit your supply chain. And advocate for stronger standards in your organizations and open source projects.

The age of implicit trust in open source is over. The age of verified supply chains has begun. Organizations serious about this need to implement the supply chain security frameworks that address these threats systematically. Every incident—from ua-parser-js to the TanStack compromise—teaches lessons that must be encoded into tooling and policy.