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.
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 | Details |
| Platform-specific payloads | Payload delivery for Windows, macOS, and Linux. |
| Persistence technique | Detached background execution designed to persist outside the install process. |
| Code indicators | Russian-language comments embedded in portions of the code. |
| Campaign consistency | 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.
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.
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.
A few things make this operation particularly notable:
176 coordinated packages is not random experimentation. It suggests automation, infrastructure preparation, and deliberate targeting.
The 99.99.99 versioning scheme strongly indicates the attackers were targeting misconfigured enterprise environments and internal package ecosystems.
The malware delivered different payloads based on operating system detection, increasing the likelihood of successful execution across developer environments and CI runners.
Environment variable theft is especially dangerous in modern pipelines where secrets, cloud credentials, registry tokens, and signing keys frequently exist in runtime environments.
One compromised build agent can quickly become a supply chain pivot point.
If any of these packages were installed, the affected host should be considered potentially compromised. Removing the dependency alone is not sufficient.
Recommended actions include:
Identify systems where the packages were installed.
Rotate exposed credentials and tokens immediately.
Review CI/CD secrets and environment variables.
Investigate outbound network connections from affected hosts.
Audit for secondary payload persistence.
Verify internal package namespace protections.
Reconfirm npm registry resolution order and scope configuration.
And yes, review whether your internal packages can accidentally resolve against public registries.
Because attackers already are.
This campaign fits a larger pattern we are increasingly seeing across npm, PyPI, and other ecosystems: Attackers are optimizing for developer workflow shortcuts, automation gaps, and trust assumptions.
Sometimes, to be successful, an attack just needs a package manager doing exactly what it was told.
That is why modern software supply chain defense has to happen before components enter the build, not after malware is already executing inside it.
Or more bluntly: Security posture does not help much once the postinstall script starts beaconing out credentials.
Sonatype is tracking this activity as Sonatype-2026-003429 — see Guide for the full list of packages.
At the time of publication, attribution remains unconfirmed. However, researchers observed Russian-language comments embedded within the codebase and coordinated infrastructure patterns across the malicious packages.
The campaign remains under active investigation.