Malicious package waves in npm and PyPI: what DevSecOps teams need now

TL;DR: A weekly scan of public registries found 180 malicious packages between July 24 and July 30, 2026, including a 55-version npm campaign and a 17-package dependency-confusion cluster targeting PayPal service names, according to Xygeni. Supply chain abuse is now fast enough to outrun weekly review cycles and create autonomous installation risk in developer pipelines.

NHIMG editorial — based on content published by Xygeni: The Registry Never Sleeps: 180+ Malicious Packages This Week

By the numbers:

• We confirmed 180 malicious packages between July 24 and July 30, 2026.
• A single npm package, zevairouter, reached 55 confirmed versions across the week.
• A 17-package cluster mimicked internal PayPal service names within the same few minutes.

Questions worth separating out

Q: What breaks when malicious packages can be published faster than teams can review them?

A: Manual review breaks first, because high-velocity publishing turns package trust into a timing problem.

Q: Why do malicious packages create identity risk as well as supply chain risk?

A: They become identity risk when install-time access includes cloud tokens, signing keys, or service credentials.

Q: How do security teams know if dependency controls are actually working?

A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach.

Practitioner guidance

• Enforce registry allowlists and source pinning Restrict installs to approved registries, pin dependency sources, and block ambiguous package resolution that can route to lookalike public packages.
• Detect version churn and namespace impersonation Flag packages that publish unusually fast, reuse internal service names, or mirror trusted tooling names across npm, PyPI, and OpenVSX.
• Isolate secrets from install-time workflows Remove cloud tokens, signing keys, and API secrets from package install and test steps so a malicious dependency cannot harvest usable credentials.

What's in the full analysis

Xygeni's full research covers the operational detail this post intentionally leaves for the source:

• Per-package malicious behaviour evidence, including the signals used to confirm abuse across npm, PyPI, and OpenVSX
• The full weekly breakdown of impersonation clusters, versioning campaigns, and registry timing patterns
• Detection and prioritisation context for DevSecOps teams that need to triage package risk at scale
• The source article's broader Malicious Code Digest framing and how these cases fit into the weekly threat picture

👉 Read Xygeni's Malicious Code Digest on 180+ malicious packages this week →

Malicious package waves in npm and PyPI: what DevSecOps teams need now?

Explore further

View Full Forum →  |  NHI Foundation Course →