CanisterWorm: Compromised npm Publisher Enables Install-Time Supply Chain Attack

In March 2026, a supply chain attack targeting the npm ecosystem exposed how trusted publisher accounts can be used to distribute malicious code at scale. In this case, attackers compromised a publisher account to inject malicious versions into widely used packages, enabling execution during install across developer and CI environments.

On March 20, 2026, researchers at Socket disclosed a supply chain attack involving a compromised npm publisher account used to distribute malicious versions across 29 packages. By March 21, the scope expanded, with 135 affected packages identified, now tracked as part of the CanisterWorm campaign.

Unlike traditional supply chain attacks that rely on introducing new dependencies, this attack leveraged existing trust relationships, allowing malicious code to execute automatically during routine installs without requiring any changes from the user.

While distinct from other recent supply chain incidents, this activity reflects a consistent pattern: attackers compromising trusted distribution channels to execute code during install and build stages. Some reporting has linked aspects of this activity to broader campaigns involving similar infrastructure, though attribution remains evolving.

What Was Affected

• 135 npm packages distributed through a compromised publisher account.
• Downstream environments that installed those versions, including:
  
  • CI pipelines
  • Developer machines
  • Build containers

These packages were already part of existing dependency trees, meaning affected versions could be pulled automatically into downstream environments during normal install and build processes.

What Happened

The attacker compromised an npm publisher account and used it to distribute malicious versions of legitimate packages; no vulnerability was exploited. This allowed them to:

• Publish new malicious versions of packages without raising suspicion. 
• Bypassed normal source-to-release workflows.
• Leveraged existing trust and dependency graphs.

The core vulnerability was a flaw in the trust model. Malicious package versions, published through a compromised, trusted account, were automatically integrated into downstream environments during standard installation and CI builds due to their wide adoption. This allowed the attack to bypass typical integrity checks, treating the dependency as legitimate and ultimately compromising systems before any code execution.

Technical Behavior

The malicious packages introduced install-time execution, typically through lifecycle scripts. Observed behavior included:

• Execution during preinstall or install phases.
• Fetching remote payloads from attacker-controlled infrastructure.
• Dynamic execution using obfuscated JavaScript.
• Environment-aware payload delivery.
• In some cases, this included execution of remote scripts immediately after package installation, before any application code was run.
  

This reflects a broader shift: execution is moving earlier in the pipeline, into install and build stages where visibility is limited.

Recent analysis suggests this activity may extend beyond initial access. Later-stage execution includes environment-aware behavior, where Kubernetes clusters may be targeted for destructive actions, while other systems receive persistent backdoors.

Impact

This class of attack targets environments where security visibility is weakest:

• Developer machines.

Since execution occurs during installation:

• It runs before application code.
• It bypasses traditional scanning checkpoints.
• It can access credentials, tokens and environment variables.

Potential impact includes:

• Credential exposure.
• Unauthorized outbound communication.
• Remote payload execution.
• Persistence mechanisms, depending on payload stage.

This effectively gives attackers execution in environments that often contain deployment credentials, API keys and access to production systems.

Why This Matters

This attack highlights a fundamental weakness in how modern software supply chains are secured. Trust is often established at the source level, assuming that published packages behave as expected. However, in this case, the source remained trusted while the behavior changed at execution time.
Traditional security measures like known-bad detection or static analysis are ineffective against this type of attack. This is because the malicious actions occur dynamically during the installation and build phases, meaning the critical factor is not the installed artifact, but the code that was executed.

Immediate Actions

1. Identify whether affected packages and versions exist in your environment.
2. Audit CI logs, lockfiles and build artifacts for installation events.
3. Treat any environment that installed these versions as potentially exposed.
4. Rotate credentials (npm, GitHub, cloud, CI tokens).
5. Update or replace affected dependencies.
6. Review lockfiles for unexpected version changes and pin dependencies to verified versions.

Affected Packages

The following packages and versions were identified as containing malicious install-time behavior. The list is tracked through Socket’s CanisterWorm supply chain attack page

References

1. Aikido Security. March 20, 2026. CanisterWorm / TeamPCP npm Supply Chain Analysis. Aikido
2. Aikido. March 22, 2026. CanisterWorm Gets Teeth: TeamPCP's Kubernetes Wiper Targets Iran. Aikido
3. iTnews. March 23, 2026. CanisterWorm Supply Chain Malware Attacks npm. iTnews
4. Socket. March 20, 2026. CanisterWorm: npm Publisher Compromise Deploys Backdoor Across 29+ Packages. Socket
5. Socket. March 20, 2026. Campaign Coverage. Socket