CanisterWorm shows how CI compromise turns into package worming

At a glance

What this is: CanisterWorm is a supply chain compromise that moved from CI/CD access into npm poisoning, secret theft, and Linux endpoint persistence.

Why it matters: It matters because software supply chain attacks now cross build systems, package registries, and developer devices, so IAM and NHI controls have to follow trust across each handoff.

By the numbers:

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

Context

CanisterWorm is a software supply chain attack that began with access to release automation and CI integrations, then expanded into package publishing and developer endpoints. The article is about how one compromise can cross multiple trust boundaries, not just how a single build system failed.

For identity practitioners, the key issue is governance of non-human credentials across the build, publish, and install path. CI secrets, npm publish tokens, and developer-host persistence all became part of the same attack surface once the initial access was obtained.

Key questions

Q: What breaks when a CI/CD compromise can republish npm packages?

A: The failure is not only secret exposure. Once a compromised build identity can also publish packages, the attacker gains a second distribution channel that can reach developers, downstream users, and additional registries. That turns one incident into a propagation loop where compromised trust in the pipeline directly feeds software supply chain spread.

Q: Why do build secrets and publish tokens create ecosystem-wide risk?

A: Because those credentials do more than authenticate a job. They can authorise artifact creation, package replacement, and malicious republishing from new environments. If a stolen credential can move from CI to a registry, then the trust boundary between build and distribution has already failed.

Q: What are the signs that package installation has become a persistence path?

A: Look for postinstall scripts that spawn unexpected child processes, user-level systemd services, suspicious files under home-directory paths, and outbound requests that continue after the package install should be complete. Those signals show that installation time is being used for code execution and long-lived presence, not just dependency setup.

Q: How should security teams respond when a supply chain compromise exposes management tooling and privileged access paths?

A: Start by assuming the compromised tooling may have exposed more than software. Identify every asset it monitored or managed, then validate patches, credentials, certificates, internet exposure, and unexpected configuration changes. Prioritise the attack surface that gives an attacker the easiest route back into the environment, because management platforms can become force multipliers for lateral movement and persistence.

Technical breakdown

CI/CD credential compromise as the first trust break

The campaign began with access tied to release automation and CI integrations, which gave attackers a foothold inside trusted build paths. Once they had that position, they could push trojanized artifacts and collect secrets such as tokens, credentials, and runtime variables from pipeline execution. That matters because CI systems often hold the highest-value non-human credentials in software delivery. A compromise at this layer is not just build tampering. It is a credential acquisition event that can unlock package publishing, source trust, and downstream distribution.

Practical implication: treat CI/CD credentials as high-value NHI assets and monitor them as actively as production secrets.

npm republishing and package worming mechanics

CanisterWorm became worm-like when stolen npm authentication tokens allowed the malware to enumerate packages, modify versions, and publish additional trojanized releases. That creates a self-propagating loop: infected hosts expose publisher credentials, and those credentials become the next distribution channel. The install-time logic matters too. A malicious package can run during installation, which means compromise can occur before a user ever opens the package. This is not just supply chain contamination. It is credential-driven propagation through a trusted registry.

Practical implication: enforce publish-token scope, review anomalous version bumps, and alert on package republishing from unexpected hosts.

Persistence through user-level services and deferred payload delivery

The malware dropped a Python backdoor and established persistence with a user-level systemd service, often named pgmon.service. That persistence pattern avoids the need for elevated privileges while keeping the payload resident across reboots. The backdoor also checked an ICP canister for instructions, which replaced a traditional centralized command-and-control server with a durable dead-drop. That architecture makes the campaign harder to disrupt because the payload source is decoupled from the initial infection path and can be updated independently of the infected host.

Practical implication: hunt for user-level persistence artifacts and unexpected outbound control channels on developer Linux systems.

Threat narrative

Attacker objective: The attacker objective was to turn one trusted CI compromise into a reusable distribution mechanism for stealing secrets, poisoning packages, and spreading malware through npm.

1. Entry occurred through credentials tied to release automation and CI integrations, allowing attackers to operate inside trusted distribution paths.
2. Credential theft followed when the initial payload collected secrets such as tokens, cloud credentials, and runtime variables from CI environments.
3. Escalation happened when stolen npm publishing credentials were used to modify packages and release additional trojanized versions.
4. Impact expanded as infected developer systems persisted the malware, enabled further package poisoning, and broadened ecosystem exposure.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package worming is the better model for this incident than simple supply chain compromise. The campaign did not stop at one poisoned build artifact. It used stolen publish credentials to create a new propagation layer inside npm, which means the attacker controlled both the initial infection path and the downstream distribution path. Practitioners should treat registry abuse as a lifecycle problem, not a one-time incident.

CI/CD secrets and npm publish tokens are the same governance problem once trust boundaries collapse. A credential in a release pipeline is not just for deployment. It can become the credential that enables package poisoning, repeated publishing, and later endpoint compromise. The practical conclusion is that build identity, registry identity, and developer-host identity need unified governance assumptions rather than separate control silos.

Ephemeral build trust does not exist if publish credentials survive the pipeline. This incident shows that short-lived execution is not enough when a stolen token can outlive the job and reappear in another context. The implication is that lifecycle controls must account for the reuse of build-issued access outside the original session, because that is where propagation begins.

Endpoint persistence on developer systems turns a package event into an identity event. Once malware lands through install-time logic and persists as a user-level service, the workstation becomes a credential source and a publishing node. That means package security, Linux endpoint monitoring, and non-human credential governance are no longer separable review streams. Practitioners should unify them in one attack-path view.

Canister-based command and control shows how supply chain attacks are borrowing resilience patterns from distributed systems. The use of an ICP canister as a dead-drop makes the control plane less dependent on a single server, which complicates takedown and detection. Security teams need to assume that future package worms will mix registry abuse with more resilient control channels, not just classic malware infrastructure.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Package worming changes the control objective. A compromised CI job is no longer just a build integrity problem if the attacker can repurpose stolen credentials to publish again from a different host. Security teams need to model the package registry as a propagation layer, not a passive repository.

Identity blast radius now spans release automation, registries, and endpoints. The same credential class can move from pipeline access to package publishing to developer-host persistence, which means separate owners cannot each certify safety in isolation. The governance model has to follow the trust chain rather than the tool boundary.

Secret leakage in CI remains the easiest way to create a wider supply chain incident. According to the State of Secrets Sprawl 2026, 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. That is why build runners must be monitored as production-grade identity assets, not disposable infrastructure.

For practitioners

• Audit CI release credentials Inventory every secret used in release automation, CI integrations, and package publishing, then classify which ones can publish artifacts or access registries. Prioritise tokens that can move from pipeline execution into external distribution paths.
• Constrain npm publishing authority Separate build access from registry publishing rights, and review whether any token can enumerate, modify, and republish packages from a compromised runner or developer host. Watch for anomalous version bumps and nonstandard publish origins.
• Hunt for user-level persistence on Linux endpoints Search developer systems for user-level systemd services, suspicious Python files under user-controlled paths, and outbound checks to unfamiliar control infrastructure. Treat package installation as a potential persistence event, not only a software install.
• Correlate build and endpoint telemetry Connect CI job execution, package install behaviour, and endpoint process activity so one compromise can be traced across the full supply chain path. Alert on install-time scripts that launch child processes, reach out to unexpected domains, or touch sensitive runtime data.
• Reduce credential reuse across trust boundaries Replace shared or long-lived credentials with narrowly scoped identities for build, publish, and endpoint actions, and separate their revocation paths. The goal is to keep one stolen token from becoming a second distribution channel.

Key takeaways

• CanisterWorm shows how a single CI compromise can become package worming when publish credentials are stolen and reused across the supply chain.
• The article identifies more than 140 affected NPM packages, which shows how quickly one trusted path can expand into ecosystem-wide exposure.
• The limiting control is not only malware detection. It is strict separation and monitoring of build credentials, registry tokens, and developer endpoint persistence.

Key terms

• Package Worming: Package worming is a supply chain pattern where stolen credentials are used to republish malicious software so one compromise can trigger the next. In practice, the package registry becomes part of the attacker’s propagation path, not just the victim’s software delivery process.
• CI/CD secret exposure: CI/CD secret exposure is the accidental or unauthorized disclosure of credentials used by build and deployment pipelines. It includes API keys, tokens, certificates, passwords, and signing material appearing in logs, code, artifacts, environment variables, or pipeline configuration. Exposure creates immediate risk because attackers can impersonate systems, alter releases, or move laterally.
• User-Level Persistence: User-level persistence is malware retention that lives under a normal user context rather than requiring administrator rights. It often uses scheduled services or startup hooks in user-owned paths, which makes it harder to spot during routine system checks and easier to survive reboots.
• Registry Publish Token: A registry publish token is a credential that authorises package creation, version updates, or release publication in a software registry. Because it can turn an endpoint into a distribution source, its scope and revocation lifecycle are central to supply chain security.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.