Malicious package campaigns are becoming multi-day, multi-registry attacks

At a glance

What this is: Xygeni reports a weekly burst of more than 130 malicious packages across npm and PyPI, with coordinated clusters, dependency confusion, and repeated version flooding standing out as the dominant pattern.

Why it matters: This matters because package ecosystems now function as identity-bearing delivery channels, so DevSecOps and IAM teams need to treat namespace trust, publisher behaviour, and publication velocity as governance signals.

Context

Public package registries are now a routine entry point for attackers because publication is cheap, names can be impersonated at scale, and malicious updates can blend into normal dependency activity. In practice, the control gap is not only malware detection but trust governance across namespaces, publisher identities, and release cadence.

This article sits at the intersection of software supply chain security and identity governance because package names, maintainer accounts, and internal namespaces are being abused as trust boundaries. For teams running DevSecOps, the question is no longer whether a package exists in a registry, but whether the publishing identity and versioning pattern deserve trust.

The pattern described by Xygeni is typical of modern supply chain abuse rather than an isolated anomaly. Attackers are using scale, speed, and registry diversity to overwhelm review processes that still assume a small number of obvious bad packages.

Key questions

Q: What breaks when dependency confusion is allowed in CI/CD pipelines?

A: Build systems can install malicious public packages instead of trusted internal dependencies, which turns normal package installation into an execution path for secret theft. The failure is not only malware execution. It is the loss of control over where code comes from and what identity-bearing material the runner exposes during install.

Q: Why do multi-day package campaigns create more risk than a single malicious release?

A: Because repeated publishing gives attackers more chances to evade review, reappear under nearby versions, and reach different consumers before one package is removed. The risk is not only the payload, but the campaign structure itself. Teams need controls that watch publication behaviour over time, not just package contents at a single point.

Q: How can security teams tell whether a package publication pattern is suspicious?

A: Look for clusters of sequential versions, reused family names, typosquat patterns, or publisher behaviour that does not match normal maintainer activity. Sudden bursts across multiple registries are especially important when the packages target authentication, wallet, or internal tooling namespaces. Those signals usually justify quarantine rather than automatic trust.

Q: Should teams treat package provenance as part of identity governance?

A: Yes. In modern software supply chains, the publisher, namespace, and registry path are trust attributes that determine whether code should be admitted into a build. Identity governance is not limited to human users and service accounts; it also applies to the identities that publish and distribute code artifacts.

Technical breakdown

How version flooding defeats registry-based trust

Version flooding is a publication tactic where attackers push many releases in a short period so one malicious package can persist even after another version is removed. That changes the defender's problem from single-package detection to lineage and cadence analysis. In package ecosystems, the release stream itself becomes part of the attack surface because consumers often pin loosely or auto-update through transitive dependencies. The result is that malicious content can stay available long enough to be installed before human review catches up.

Practical implication: Treat unusual release velocity as a control failure signal and block packages that show bursty, low-signal publishing patterns.

Why namespace impersonation works in npm and PyPI

Namespace impersonation relies on users trusting a package name, scope, or maintainer pattern that resembles a legitimate internal or ecosystem package. Attackers exploit lookalike names, scoped namespaces, and internal-package confusion to cross the boundary between trusted and untrusted code. The technical weakness is not the syntax of the package manager, but the absence of strong identity binding between the publisher and the dependency consumer. Without verified provenance, a registry listing can look legitimate even when the publishing identity is not.

Practical implication: Verify publisher identity and package provenance before allowing internal namespaces or ecosystem lookalikes into build pipelines.

How dependency confusion turns internal naming into an attack path

Dependency confusion appears when a build system resolves a package name to a public registry because the internal package name is not tightly governed or pinned. If the public package wins resolution, the attacker gains a path into the software supply chain without compromising the internal environment directly. This is a governance failure around naming, repository precedence, and build-time resolution rules. The attacker does not need privileged access to the target organisation, only a package name that the build system is willing to trust.

Practical implication: Lock down package resolution order and inventory internal namespaces so public registries cannot satisfy names that should remain private.

Threat narrative

Attacker objective: The attacker aims to get malicious code or credential-stealing logic into trusted builds and downstream developer environments at scale.

1. Entry occurs when attackers publish malicious packages into npm or PyPI using typosquats, impersonated namespaces, or dependency confusion names.
2. Credential or code-path access follows when victim build systems install the package and execute its install or runtime logic.
3. Escalation happens as the malicious package reaches development, CI, or downstream environments through trusted dependency workflows.
4. Impact is achieved through payload execution, credential theft, or supply chain compromise across multiple registries and release cycles.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package publishing is now an identity problem, not just a malware problem: the trust decision is increasingly about who published a package, under what namespace, and with what release behaviour. That means software supply chain controls have to evaluate publisher identity and package provenance alongside static scanning. Practitioners should treat registry identity as part of access governance.

Multi-day version flooding is a named control failure, not just noisy attacker behaviour: attackers are exploiting the gap between publication speed and human review capacity. When dozens of releases appear across multiple days, the governance assumption that maintainers and scanners can review each artefact one by one no longer holds. Practitioners need to key controls to publication patterns, not only package content.

Dependency confusion remains one of the clearest examples of trust boundary collapse in modern build systems: internal package names are being treated as if they were safely private when build resolution still allows public substitution. That creates a predictable path from naming ambiguity to code execution. Practitioners should regard internal namespace governance as a supply chain control, not a developer convenience.

Malicious registry activity is becoming a persistence strategy, not a one-off dropper event: attackers increasingly use repeated publishing, closely related package families, and overlapping registries to stay present even after individual packages are removed. That shifts the defender's job from remediation to continuous admission control. Practitioners should expect the campaign, not the single package.

What this signals

Namespace trust is now a control plane decision: security teams should treat package resolution rules, registry precedence, and publisher verification as admission controls rather than developer preferences. Once internal and public namespaces can collide, a build pipeline is effectively making an identity decision every time it installs a dependency.

Campaign-style package abuse will keep outpacing manual review: bursty publication, repeated versioning, and cross-registry activity create enough noise to exhaust human triage. The more sustainable response is to move trust decisions earlier, into source approval, namespace governance, and automated provenance checks.

For practitioners

• Harden internal package namespace governance Reserve private names, enforce registry precedence rules, and block public packages from satisfying names that belong to internal scopes or product families.
• Flag burst publishing as a risk signal Alert on multiple releases from the same package name, maintainer, or closely related family over a short window, especially when the versions are inconsistent or heavily sequential.
• Require provenance checks before build consumption Gate dependency ingestion on maintainer verification, package lineage, and approved registry source rather than package name alone.
• Quarantine lookalike ecosystem packages Place typosquats and impersonation candidates into a review queue before they reach CI, especially where the package targets authentication, wallet, crypto, or internal platform workflows.

Key takeaways

• Malicious package abuse is moving beyond isolated typosquats into sustained campaigns that exploit trust in registries, namespaces, and release cadence.
• The core weakness is governance, not just detection: build systems often trust package identity and provenance too loosely.
• Teams need to control namespace ownership, provenance, and publication behaviour before packages are admitted into CI/CD.

Key terms

• Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
• Typosquat Package: A typosquat package is a malicious or misleading package name designed to resemble a legitimate dependency. Attackers rely on typing mistakes, autocomplete, or familiarity to get developers to install it, then use the trusted package manager path to deliver payloads or steal data.
• Prompt Flooding: Prompt flooding is the operational pattern behind MFA fatigue attacks, where a large number of approval requests are generated in a short period. In human identity programmes, it is a useful detection signal because legitimate logins rarely create a sustained burst of repeated prompts from the same account.
• Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to software supply chain risk and broader access governance.