CanisterWorm: When a CI/CD Breach Became a Self-Spreading npm Worm

A supply chain compromise moved from CI pipelines into the npm ecosystem, stealing secrets, hijacking packages, and persisting on developer systems through a novel malware design.

Executive Summary

Software supply chain attacks are no longer isolated build-time incidents. Increasingly, they are multi-stage campaigns that move across trust boundaries: from CI/CD pipelines to developer workstations, from package registries to publisher accounts, and from a single compromise to broad ecosystem exposure.

CanisterWorm is a strong example of that shift.

What began as a compromise tied to release automation for a widely used security tool evolved into a broader campaign involving malicious package publishing, credential theft, developer workstation persistence, and one of the more unusual command-and-control designs seen in a supply chain attack to date: an Internet Computer Protocol (ICP, an expansion on smart contracts) canister used as a resilient dead-drop for payload delivery.

This incident matters not only because of its impact, but because of what it reveals about the next generation of software supply chain threats.

From trusted pipeline to poisoned package

The campaign started with access to credentials tied to release automation and CI integrations. With that access, attackers were able to push trojanized artifacts and manipulate trusted distribution paths, causing downstream users to consume malicious code through channels that normally appear legitimate.

The initial payload functioned as an infostealer, designed to run in CI/CD environments and collect secrets such as tokens, credentials, and runtime variables. That first stage gave the attackers what they needed to escalate the campaign: access to package publishing credentials.

From there, the operation expanded into npm. Dozens of packages were republished with malicious install-time logic, allowing the attackers to move beyond CI systems and into developer endpoints and other environments that installed the compromised packages.

What makes CanisterWorm different

CanisterWorm stands out because it blends several attack techniques into a single propagation model.

A malicious npm package executes a postinstall script during installation. That script drops a Python-based backdoor onto the system and establishes persistence using a user-level systemd service, often named pgmon.service. The malware is typically written under the user’s home directory, allowing it to survive reboots and continue operating without elevated privileges.

Once installed, the backdoor waits and periodically checks a remote ICP canister for updated instructions. Instead of relying on a traditional centralized command-and-control server, the malware uses the canister as a durable intermediary that can point infected systems to follow-on payloads.

That design gives operators flexibility and resilience. It also makes the campaign notable from a research perspective, as it reflects a shift toward more decentralized and less conventional control channels in malware operations.

Why this became a worm

The malware looks for npm authentication tokens on the infected host. If it finds valid publisher credentials, it can enumerate accessible packages, modify them, increment versions, and publish additional trojanized releases. In other words, one compromised machine can become a new distribution point.

That is the critical transition point from supply chain attack to worm-like behavior.

Instead of relying solely on the original compromise, the malware can leverage stolen credentials from each newly infected environment to expand further into the ecosystem. This creates a feedback loop: compromise leads to token theft, token theft leads to malicious publishing, and malicious publishing leads to more compromise.

What the impact looks like

Organizations exposed to the affected artifacts should think beyond a narrow package-level incident.

The likely blast radius includes both CI/CD infrastructure and developer endpoints, with potential consequences such as:

• Theft of CI/CD secrets, cloud credentials, source control tokens, and registry credentials
• Compromise of npm publish tokens and abuse of internal or public packages
• Persistence on Linux developer systems through rogue systemd user services
• Follow-on malware delivery through the ICP-based control path
• Potential lateral movement using credentials collected from runners and workstations

The attack also demonstrates how quickly trust can collapse across environments. A pipeline compromise can lead to poisoned packages. Poisoned packages can compromise workstations. Workstations can expose publisher credentials. Those credentials can then be used to infect even more packages and users.

What defenders should investigate

For security teams, this is the kind of incident that requires visibility across build systems, package activity, and endpoints.

To date, over 140 affected NPM packages have been identified.

On Linux systems, defenders should look for persistence artifacts such as:

• ~/.config/systemd/user/pgmon.service
• suspicious Python files under user-controlled paths such as ~/.local/share/pgmon/

Additional investigation areas should include:

• Unexpected outbound connections, including requests to *.raw.icp0[.]io
• Package installations that triggered unusual child processes or network access
• Suspicious npm publish activity, especially unexpected version bumps
• CI jobs that executed compromised package versions or affected GitHub Actions
• Access to sensitive runtime data such as /proc/*/environ or /proc/*/mem inside build environments

If your organization publishes packages, unusual release activity during the exposure window should be treated as potentially high priority. Given that this is a rapidly developing incident, all impacted teams should continuously monitor the official advisory for affected components and recommended actions.

How Orca Can Help

The Orca Cloud Security Platform enables security teams to respond to supply chain threats like CanisterWorm within minutes.

• Instant Discovery and Visibility: Identify the compromised assets across the blast radius, including affected CI/CD infrastructure, developer pipelines, and affected NPM packages.
• Context-Aware Prioritization: See which vulnerable assets are internet-facing, in production, or contain sensitive data – focus on what matters first.
• Attack Path Analysis: Map the critical transition points, such as the persistence artifacts (pgmon.service and suspicious Python files) on Linux systems and the exposure of sensitive secrets (tokens, cloud credentials) that lead to further package poisoning.
• Targeted Remediation: Pinpoint and investigate suspicious activity related to the attack, including unexpected outbound connections, unusual child processes during package installation, and suspicious npm publish activity.

Using Orca’s News Item, view highlights affected assets directly, helping security teams cut through the noise and focus on the instances that matter most.