TL;DR

• An open source malware campaign dubbed CanisterSprawl has been observed in npm, stealing sensitive data from developer machines including tokens, API keys, and more.

• From there, the malware publishes additional compromised packages under hijacked credentials, abusing developer trust in open source ecosystems to spread.

• Impacted organizations should remove the malware immediately, examine exposed secrets, and monitor for compromised publishing.

A newly disclosed malicious npm campaign (by StepSecurity and Socket), CanisterSprawl, is drawing attention for how effectively it pairs data theft with attempted account abuse, underscoring how quickly a single package install can escalate into broader software supply chain risk. Sonatype caught and quarantined all packages associated with this campaign.

Rather than remaining confined to a single compromised environment, this campaign appears designed to extend its reach by leveraging access gained during installation. That shifts the risk from isolated package malware to a potential pathway for wider ecosystem impact.

This is more than a case of isolated package malware. The immediate concern is the theft of local system and environment data, but what's more consequential is the apparent effort to abuse publisher access, potentially allowing attackers to use a trusted account to distribute additional malicious packages.

What Is Self-Propagating Malware?

Self-propagating malicious packages, sometimes called worm-like malware, do not need to exploit a complex technical weakness to create serious downstream risk. They only need to get installed in a trusted development environment.

Once installed, these packages can inspect the local system, harvest sensitive data, and interact with credentials or configuration files already present on the host.

In the case of CanisterSprawl, the added risk comes from the package's apparent attempt to publish malicious components under the victim's account. That shifts the threat from a single compromised machine to potential ecosystem-wide abuse through trusted publisher channels.

Attacker Automation Turns Stolen Credentials Into Trust Abuse

The malicious packages contain embedded code that executes automatically during installation. Once triggered, the malware:

• Scans environment variables seeking credentials and developer tokens

• Harvests browser credentials, crypto wallet data, and configuration files containing credentials

• Exfiltrates collected data to an external server

• Attempts to publish malicious packages using the victim’s account

• Looks for an npm automation token machine and, if found, lists all the packages the token grants ‘write’ access to.

• Then it downloads the packages, injects the malicious script itself into them, and re-publishes them to the registry. 

Even seemingly basic system data can provide attackers with valuable insight. Environment variables, in particular, often contain API keys, authentication tokens, internal service endpoints, deployment configurations, and other sensitive information.

The attempted publishing behavior is especially notable. It suggests the attacker's goal may not stop at local reconnaissance or data theft, but may extend to reusing compromised access to place new malicious packages into the ecosystem under the cover of a legitimate account.

As of this writing, compromised accounts include:

• @automagik/genie (4.260421.33 - 4.260421.40)

• @fairwords/loopback-connector-es (1.4.3 - 1.4.4)

• @fairwords/websocket (1.0.38 - 1.0.39)

• @openwebconcept/design-tokens (1.0.1 - 1.0.3)

• @openwebconcept/theme-owc (1.0.1 - 1.0.3)

• pgserve (1.1.11 - 1.1.14)

Downstream Risk and Ecosystem Impact

Any environment that installed the package should be treated as potentially exposed. The most immediate risk is data exfiltration from the host.

However, the more serious downstream concern is whether stolen credentials or access tokens could be used for further malicious activity, including:

• Unauthorized package publishing.

• Account takeover or abuse.

• Lateral movement into other systems or services.

• Compromise of downstream consumers.

This risk is amplified in developer and CI/CD environments, where environment variables and local configurations often contain privileged credentials. A single successful installation in these contexts can have cascading effects well beyond the original system.

This incident also reinforces how effective package impersonation remains. By mimicking legitimate dependencies, malicious packages can blend into routine workflows. In fast-moving development environments, a minor naming discrepancy can be enough to trigger execution within a trusted pipeline.

Recommended Actions

If your environment installed a malicious package, remove it immediately. Because this campaign steals sensitive data, organizations that have been impacted should also:

• Investigate what data may have been exposed from the affected host.

• Rotate any potentially compromised credentials, tokens, or API keys.

• Review environment variables and local credentials for possible compromise.

• Audit account activity for unauthorized publishing or access.

• Verify dependency names and sources before reinstalling packages.

• Confirm manifests and lockfiles do not reference an impersonating package.

How Sonatype Helps Protect Against This Growing Pattern

Modern package-based attacks are increasingly designed to appear benign long enough to gain execution in environments that already contain valuable secrets and privileged access. Once inside, even lightweight malicious behavior can have outsized consequences.

That is why incidents like CanisterSprawl matter.

The package itself is only the entry point. The real target is the surrounding environment: credentials, tokens, and trusted access paths.

Defending against this type of threat requires more than manual review or reactive controls. Organizations need the ability to identify and block malicious components before they are introduced into developer and build environments.

Security controls that evaluate component risk at the point of consumption can help prevent install-time malware from executing. Combined with high-quality package intelligence, these controls enable teams to distinguish legitimate dependencies from lookalikes and other high-risk components.

In fast-moving ecosystems like npm and PyPI, that proactive approach is critical. Once a malicious package reaches a trusted environment, the problem is no longer just a bad dependency. It becomes a broader incident involving exposed secrets, compromised accounts, and potential downstream impact.