Npm worm spreads through developer environments and steals secrets

A new self-propagating malware campaign is spreading through npm packages tied to Namastex Labs, according to security vendors Socket and StepSecurity. The strain is stealing secrets from developer environments and then trying to move on to additional packages, which makes it more than a simple one-off compromise.

npm is the package manager used by millions of JavaScript and Node.js developers. When a package is installed, its scripts can run automatically, which gives attackers a way to execute code on developer machines, build servers, and CI systems if they can get malicious code into a trusted package.

Socket said the latest activity overlaps with earlier CanisterWorm infections. That earlier worm has been associated with package-tampering campaigns that use the npm ecosystem itself as a distribution channel, allowing malicious code to spread from one compromised package to another without requiring a traditional phishing step or manual installation by the victim.

In this case, the malware is described as self-propagating, meaning it attempts to copy itself into other packages after it lands in an environment. The goal is not just to steal credentials, but also to use those credentials or publishing access to extend the compromise across more of the software supply chain.

Security researchers have been watching supply chain abuse in npm for years because the registry sits directly in the path of everyday development work. Developers pull in dependencies constantly, often with limited review of transitive packages, and attackers exploit that trust by targeting package maintainer accounts, publishing workflows, or build-time execution paths.

The mention of Namastex Labs is significant because package publishers often have broad access to their own ecosystem. If attackers can compromise one package maintainer account or one machine with stored secrets, they may be able to poison multiple releases or publish lookalike updates before the issue is detected.

Socket and StepSecurity both focused on the infection behavior and the spread across npm, but Socket stopped short of saying this latest incident should be attributed to TeamPCP. That caution matters because supply chain investigations often start with overlapping infrastructure, similar malware traits, or shared code, but attribution can take longer than the initial technical analysis.

The attack also fits a familiar pattern in modern software compromise. Rather than trying to break into one company through a perimeter system, attackers increasingly target the tools developers trust most, then use those tools to reach code repositories, cloud credentials, and downstream users.

That makes install-time execution a particularly sensitive point in the software build process. If a package runs scripts during installation, those scripts can access environment variables, local configuration, tokens, and cached credentials, depending on how the workstation or build agent is set up.

For npm users, the practical problem is that a single compromised dependency can affect a wide range of projects very quickly. Packages are reused across applications, and once malicious code is published, other developers may fetch it automatically as part of normal installs or updates.

The current campaign is another example of why npm supply chain incidents keep landing hard in developer-heavy environments. Even when the malware is discovered quickly, the presence of secrets on developer machines and in CI pipelines gives it a lot of places to look, and a lot of chances to spread before anyone notices the package has been altered.