A 176-Package NPM Campaign Built to Beat Your Internal Dependencies

speckx1 pts0 comments

Inside a 176-Package npm Campaign Built to Beat Your Internal Dependencies

Site Search

Site Search

Login

Contact Us

Book a Demo

This is a search field with an auto-suggest feature attached.

There are no suggestions because the search field is empty.

Resources

Blog

Inside a 176-Package npm Campaign Built to Beat Your ...

Inside a 176-Package npm Campaign Built to Beat Your Internal Dependencies

May 28, 2026

By Sonatype Security Research Team

6 minute read time

The latest malware campaign uncovered by Sonatype researchers involved 176 malicious npm packages, many published with the exact same version number: 99.99.99.

The versioning strategy was not subtle, and likely was not intended to be.

This is a dependency confusion trick designed to win package resolution races against internal or private packages. In short, attackers aim to deduce the internal package names of their target, and publish a similarly named package to a public registry with a high version number.

If a customer's SDLC is not set up to defend against it, npm may prefer the higher semantic version over the intended internal dependency. And 99.99.99 tends to beat just about everything.

What We Found

Sonatype researchers identified a coordinated set of malicious npm packages containing embedded postinstall scripts designed to execute automatically during package installation.

The behavior chain is straightforward and effective:

The package fingerprints the host environment.

It downloads a platform-specific JavaScript payload.

The payload performs additional reconnaissance and exfiltration.

A second-stage platform-specific binary is downloaded and executed.

The malware attempts to collect and exfiltrate:

Usernames and hostnames.

Operating system and architecture details.

Current working directories.

Node.js runtime information.

Environment variables.

CI/CD secrets.

Authentication tokens and credentials.

In other words, the exact data attackers want from developer workstations and build systems.

Key Point<br>Details

Platform-specific payloads<br>Payload delivery for Windows, macOS, and Linux.

Persistence technique<br>Detached background execution designed to persist outside the install process.

Code indicators<br>Russian-language comments embedded in portions of the code.

Campaign consistency<br>Shared infrastructure and behavior across all 176 packages.

Some of the Linux and macOS binaries already trigger antivirus detections. The Windows payload currently has fewer detections, which is usually not the sentence defenders want to read before coffee.

Why the Fake Version Numbers Matter

Many of the malicious packages used unusually high semantic version numbers like:

99.99.99

9.9.9

9.9.10

10.10.10

11.11.11

This campaign appears consistent with dependency confusion tactics, where attackers publish packages to public registries using names that may overlap with internal enterprise dependencies. If a package manager resolves the public package first, especially one with a higher version number, the attacker's package can be installed automatically inside developer or CI/CD environments.

The attackers are not trying to fool developers into thinking these are mature software releases. They are trying to fool automated dependency resolution.

Modern software supply chain attacks increasingly target build behavior itself: version precedence, namespace assumptions, install scripts, and developer workflow automation.

The Real Problem: Install-Time Trust

npm's postinstall functionality is incredibly useful. It is also one of the most abused execution points in the modern software supply chain.

The moment developers install a package, they implicitly trust:

the package author,

the transitive dependency chain,

the install scripts,

the infrastructure hosting secondary payloads,

and whatever happens after the package executes locally.

That is a large trust boundary for a command most developers run reflexively. This campaign takes full advantage of that reality.

The malicious packages did not require a user to manually execute malware. The installation process handled that automatically.

By the time a developer notices suspicious network traffic or a strange background process, the second-stage payload may already be running.

Why This Campaign Stands Out

A few things make this operation particularly notable:

Scale

176 coordinated packages is not random experimentation. It suggests automation, infrastructure preparation, and deliberate targeting.

Dependency Confusion Tactics

The 99.99.99 versioning scheme strongly indicates the attackers were targeting misconfigured enterprise environments and internal package ecosystems.

Cross-Platform Targeting

The malware delivered different payloads based on operating system detection, increasing the likelihood of successful execution across developer environments and CI runners.

CI/CD Credential Targeting

Environment variable theft is especially dangerous in modern...

package campaign internal packages version dependency

Related Articles