CanisterWorm shows how CI compromise turns into package worming

At a glance

What this is: CanisterWorm is a supply chain campaign that moved from CI access into npm package poisoning, secret theft, and persistent workstation compromise.

Why it matters: It matters because IAM, PAM, and NHI teams must treat build systems, registry credentials, and developer endpoints as one connected identity attack surface rather than separate domains.

👉 Read Orca Security's analysis of the CanisterWorm supply chain campaign

Context

Software supply chain compromise happens when attackers abuse trusted build, package, or publishing paths to deliver malicious code through legitimate channels. In this case, the primary identity problem is not just code integrity. It is the misuse of non-human identities across CI/CD, package publishing, and developer systems, where stolen secrets can move an attack from one environment into the next.

CanisterWorm illustrates how quickly trust boundaries can fail when release automation, registry credentials, and endpoint persistence are chained together. The article also shows a broader pattern that is becoming familiar across NHI programmes: one credential set can become both the initial access point and the propagation mechanism for further compromise.

Key questions

Q: What breaks when CI/CD credentials are reused for package publishing?

A: Reusing CI/CD credentials for package publishing collapses two trust functions into one non-human identity. A compromise in the build path can then mutate into malicious release authority, letting attackers publish trojanized artifacts and extend the attack into downstream environments. Separate credentials, scopes, and approval paths are the control boundary that prevents this from becoming a propagation channel.

Q: Why do package registry credentials create ecosystem risk?

A: Package registry credentials matter because they control what the ecosystem consumes, not just what a single team deploys. If those credentials are stolen, attackers can republish malicious versions, poison trust in legitimate packages, and use one compromised account to seed many victims. Registry identities must therefore be governed as distribution infrastructure, not ordinary access tokens.

Q: How do security teams detect malware persistence on developer systems?

A: Security teams should look for user-level services, unexpected startup entries, and payloads stored under user-controlled paths because modern malware often avoids admin privileges. In this case, the key indicators include systemd user services, suspicious Python artefacts, and remote instruction polling. Endpoint telemetry must be correlated with package installation and credential use to see the full chain.

Q: Who is accountable when a supply chain compromise spreads through trusted credentials?

A: Accountability usually spans release engineering, platform security, and identity governance because the incident crosses multiple trust domains. The practical question is which team owns credential scope, publish rights, and offboarding for automation identities. Frameworks such as NIST CSF and NHI governance models help assign control ownership where a single compromise can affect many systems.

Technical breakdown

CI/CD credential theft and release automation abuse

The first stage in this campaign began with credentials tied to release automation and CI integrations. Once those credentials were abused, attackers could push trojanized artifacts through channels that normally carry trusted updates. That matters because build systems often inherit broad access to source control, package registries, and runtime variables, which makes them high-value NHI targets. In practice, the compromise is not limited to a single pipeline run. It creates a trusted distribution path for malicious code and a downstream secret collection opportunity inside the build environment.

Practical implication: treat CI credentials as high-risk NHI secrets and isolate release automation from general-purpose build access.

npm package poisoning and token-driven propagation

After gaining package publishing credentials, the campaign expanded into npm through malicious republishing and install-time execution. A compromised package can run code when installed, which means the attack reaches developer endpoints and any environment that consumes the package. The worm-like behaviour comes from token theft on infected hosts. If the malware finds valid npm publisher credentials, it can enumerate packages, modify versions, and publish new trojanized releases. This turns credential theft into an ecosystem propagation mechanism rather than a single-host compromise.

Practical implication: monitor publish activity, token scope, and version changes together because package credentials can become a distribution channel.

Persistence on developer systems through user-level services

CanisterWorm drops a Python backdoor and establishes persistence with a user-level systemd service, often named pgmon.service. Because it runs under the user’s home directory, it can survive reboots without elevated privileges. The malware then checks a remote ICP canister for instructions, using that canister as a durable dead-drop rather than a conventional command-and-control server. This design makes the campaign more resilient and harder to disrupt, because the control path is decoupled from a single central endpoint.

Practical implication: hunt for user-level persistence artefacts on developer endpoints, not just kernel or admin-level indicators.

Threat narrative

Attacker objective: The attacker objective is to turn one trusted build compromise into a self-propagating supply chain foothold that steals secrets and republishes malicious packages at scale.

1. Entry: Attackers obtained credentials tied to release automation and CI integrations, then used that access to push trojanized artifacts through trusted distribution paths.
2. Credential access: The initial payload collected secrets from CI/CD environments, including tokens, credentials, and runtime variables that could be reused for further compromise.
3. Escalation: Stolen npm publisher credentials enabled malicious republishing, package version changes, and expansion from one infected environment into many downstream installations.
4. Impact: The campaign combined workstation persistence, package poisoning, and repeated credential abuse to widen blast radius across CI systems, developer endpoints, and the npm ecosystem.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Supply chain compromise is now an identity problem before it is a code problem. CanisterWorm succeeded because trusted non-human identities in CI/CD and package publishing were allowed to move code across environments without strong containment. The attack did not need to break the software model first, it only needed to inherit the trust model already attached to release automation. Practitioners should treat build-path credentials as enforcement points, not convenience tokens.

Package publishing credentials have become propagation credentials. Once the attacker obtained npm publisher access, one compromised machine could mint the next infection wave by republishing trojanized releases. That is a different governance problem from simple secret theft because the credential is not only protecting access, it is enabling distribution. The practical conclusion is that registry identity, versioning authority, and device trust are now inseparable in package ecosystems.

Ephemeral trust boundaries fail when attacker logic crosses CI, endpoint, and registry layers in one chain. The campaign shows that a clean separation between build systems and developer workstations is often more architectural fiction than operational reality. Secrets collected in one layer become the access path into the next layer, then back into the registry again. Security teams should assume a single compromised NHI can now act as both consumer and publisher of malicious code.

Internet Computer Protocol canister control is a resilience layer for malware, not just an oddity. The use of a canister as a dead-drop illustrates that supply chain threat actors are experimenting with more durable control planes that do not depend on a single obvious server. That broadens the detection problem for defenders and weakens assumptions built around simple domain blocking. Practitioners should expect control-path diversity to increase in future software supply chain attacks.

Secret sprawl is the enabling condition that turns compromise into ecosystem spread. This campaign depended on credentials being available in build and host contexts where they could be harvested, reused, and escalated. Once secrets exist in multiple environments, the blast radius becomes a governance problem rather than a single incident response task. The lesson for the field is that NHI lifecycle control has to extend across CI, endpoint, and registry identities at the same time.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 52 NHI Breaches Analysis shows how exposed credentials repeatedly turn initial compromise into wider identity failure across environments.

What this signals

Secret sprawl is the real multiplier in supply chain compromise: if one stolen credential can still remain exploitable long after discovery, the response problem is not just detection but revocation across build, registry, and endpoint identities. For practitioners, that means secret lifecycle control has to be treated as an operational containment function, not a back-office hygiene task. See the Guide to the Secret Sprawl Challenge for the identity-side mechanics behind this pattern.

With 28% of secrets incidents now originating outside code repositories in Slack, Jira, and Confluence, the boundary for pipeline defense has already expanded beyond source control. Teams should expect more exposure to come from collaboration systems, ticketing, and developer tooling than from the repository alone. That shifts monitoring and offboarding priorities toward the full working surface of engineering identities.

The next governance step is to connect package publishing rights, developer workstation posture, and CI secret inventory into one control view. NIST CSF 2.0 remains useful here because the issue spans identify, protect, detect, and respond functions at once. Treat the release path as an identity chain, not a set of isolated tools.

For practitioners

• Separate build authority from publish authority Restrict release automation so the credentials used to build software cannot also publish packages or modify registry metadata. Use narrowly scoped non-human identities for each stage and rotate them independently to prevent one compromised pipeline from becoming a distribution engine.
• Hunt for user-level persistence on developer endpoints Look for systemd user services, unexpected Python payloads under home directories, and unusual outbound connections to raw.icp0.io domains. Add these checks to endpoint triage because the malware survives without elevated privileges and can hide in normal developer activity.
• Review npm publisher tokens and package versioning rights Inventory who can publish, who can bump versions, and which tokens remain valid across maintainers, automation, and third parties. A publish token should never be assumed safe simply because it lives inside a CI or developer workflow.
• Correlate build logs with secret access events Cross-check package installation events, CI job execution, and access to runtime variables such as /proc/*/environ or /proc/*/mem. This helps identify the point where a trusted build path became a secret-harvesting path.

Key takeaways

• CanisterWorm shows that supply chain compromise now travels through identity trust as much as through software trust.
• Stolen build and registry credentials can turn a single intrusion into repeated malicious publishing across the ecosystem.
• Containment depends on separating release authority, watching for user-level persistence, and treating secrets revocation as urgent.

Key terms

• Supply Chain Identity Compromise: A supply chain identity compromise is when attackers abuse trusted automation, publishing, or registry credentials to move malicious code through legitimate software distribution paths. The core problem is not only code tampering, but the misuse of non-human identities that already possess distribution authority.
• Publisher Token: A publisher token is a secret that authorises package publication or version changes in a registry. In practice it functions like distribution authority, because anyone who holds it can turn a trusted package into a delivery mechanism for malicious code.
• 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.
• Secret Sprawl: Secret sprawl is the spread of credentials, tokens, and API keys across too many tools, systems, and workflows. The more places secrets live, the more likely one exposure becomes many exposures, and the harder it is to revoke, audit, and contain them quickly.

Deepen your knowledge

Software supply chain identity risk is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is dealing with CI/CD credentials, package publishing rights, or developer endpoint exposure, it is worth exploring.

This post draws on content published by Orca Security: CanisterWorm supply chain compromise in CI pipelines and npm. Read the original.