The 2026 npm Supply-Chain Attack Survey, Q2

Quarterly tracking of malicious-package incidents in the npm ecosystem. April 2026 set a new record: 847 confirmed malicious packages identified and removed in 30 days. This post covers the patterns, the major incidents, and what runtime detection looks like in 2026.

The numbers

Despite the overall increase, time-to-removal has improved. The industry detection layer (Socket, Snyk, npm's own moderation) is faster than it was 18 months ago. The bad news: attackers are responding by shipping packages with shorter expected lifespans — fast extraction before detection.

Major incidents this quarter

Three incidents that stand out:

1. The "@types/" dependency-confusion campaign (April 12)

A coordinated upload of 47 packages mimicking popular @types/* definitions but with actual code in postinstall hooks. Targeted developers who typed package names quickly and didn't double-check the scoped name.

What it did: read ~/.aws/credentials, ~/.ssh/id_rsa*, and any .env files in the install path. Exfiltrated to a Ngrok tunnel.

Detection time: 14 hours after first malicious upload. ~3,700 unique download IPs in that window.

Lesson: pre-install registry scanning catches obvious typos. Runtime detection catches the credential exfiltration even if pre-install missed it.

2. The legitimate-package takeover (April 19)

A long-abandoned package with ~80K weekly downloads was taken over via a maintainer-account compromise. The attacker pushed v3.4.1 with malicious postinstall code that installed a coinminer.

What it did: downloaded a coinminer binary from a CloudFlare Workers URL, executed it as a background process. CPU usage of affected dev machines / build servers spiked to 100%.

Detection time: 6 hours (the CPU spike was the giveaway in CI environments). Removed within 8 hours.

Lesson: legitimate packages can become malicious overnight. Pinning to specific versions doesn't help if you're auto-upgrading minors. Lockfile review at PR time matters.

3. The build-tool watering-hole (April 27)

A popular build tool's plugin ecosystem was compromised — three plugins published on the same day with malicious code. The attack targeted CI environments specifically: the malicious code only activated when process.env.CI === 'true'.

What it did: in CI builds, exfiltrated environment variables (often including NPM_TOKEN, AWS_*, DEPLOY_* secrets) to an attacker-controlled domain.

Detection time: 9 hours. The attack was particularly insidious because dev machines never showed the malicious behavior — only CI did.

Lesson: CI environments need their own runtime detection. Endpoint-protection software on developer machines catches a lot but doesn't run in CI.

Detection patterns that work

The runtime-side detection (vs static / pre-install scanning) caught the second and third incidents above. Patterns we observed:

1. Unexpected network calls during install or runtime. Packages that previously made no network calls suddenly making them. The SecureNow runtime hook flags this — see the AbuseIPDB integration post for cross-referencing destination IPs.

2. Process-level CPU/memory anomalies. Coinminers are obvious in CPU; credential exfiltrators are subtler. A general "any new process forked from a Node app" alert catches both.

3. Filesystem reads outside the package directory. A package reading ~/.aws/credentials is almost never legitimate.

4. CI-specific behavior. Code that activates only when process.env.CI === 'true' is a strong signal of attack. Even legitimate testing libraries don't usually have CI-specific malicious-looking branches.

What to do this quarter

Three concrete actions:

1. Add Socket or Snyk to your CI. Pre-install scanning catches the obvious. Cost: $0 for personal accounts, ~$100/mo for organization.

2. Pin and lockfile-review. Even if you didn't catch a malicious package at install, pinning to a known-good version with a hash means the next deploy doesn't pick up the compromised version. Tools like Renovate make lockfile review a PR comment, not a manual chore.

3. Runtime detection in production. Even if a package made it through pre-install scanning, runtime detection catches the exfiltration phase. The SecureNow firewall flags outbound calls to known-bad destinations; full SecureNow flags any suspicious behavior pattern.

What's coming

The trend lines to watch through Q3:

• AI-generated packages. We've started seeing malicious packages with code that's clearly LLM-generated (consistent style, comprehensive comments, reasonable-looking error handling). The malicious payload is buried in legitimate-seeming logic. Hardest variant to detect by static analysis.
• Multi-stage attacks. Initial package download is benign. The first runtime invocation downloads the actual payload from a remote URL. Splits the attack across registry and runtime, defeating each individually.
• Dependency-confusion v2. Internal-package-name leaks are still happening. Companies whose CI logs leak internal package names are still getting hit by external uploads with the same name.

Related

• AbuseIPDB threat intelligence enrichment
• Axios npm compromise detection guide
• Application security monitoring guide