CanisterWorm shows how npm token theft becomes ecosystem spread

At a glance

What this is: StepSecurity tracks CanisterWorm as a self-propagating npm worm that uses stolen publishing tokens to backdoor packages and extend compromise across the ecosystem.

Why it matters: It matters because CI/CD token theft can become package ecosystem spread, which forces IAM, NHI, and supply-chain teams to treat publishing credentials as high-impact production assets.

Context

CanisterWorm is a supply-chain compromise pattern in which stolen publishing credentials are converted into automated malware propagation through trusted package workflows. The security gap is not only secret exposure, but the assumption that package publishing tokens are low-risk development artefacts instead of high-value credentials with ecosystem reach.

The article links the worm to the second Trivy compromise and shows how a single pipeline exposure can cascade into package poisoning, persistence on developer systems, and further token theft. That intersection is especially relevant to NHI governance because npm tokens, CI/CD runners, and automated release workflows are all non-human identities in practice, even when they are handled like routine build secrets.

Key questions

Q: What breaks when npm publishing tokens are stolen from CI/CD environments?

A: When npm publishing tokens are stolen, attackers can impersonate maintainers, publish backdoored versions, and move from one compromised workflow to many affected namespaces. The practical failure is not just secret loss, but trust collapse across the package supply chain. Treat the token as a high-risk non-human identity with revocation, scoping, and audit requirements.

Q: Why do stolen CI tokens and publishing tokens create such a large blast radius?

A: Because they are non-human identities with operational authority, not just authentication artifacts. A single token can publish malicious versions, create branches, trigger workflows, or read repository state. When scope is broad or lifecycle is weak, compromise spreads faster than manual review can contain it. Narrow scope and rapid revocation are essential.

Q: What are the signs that a package install is behaving like malware rather than ordinary dependency setup?

A: Warning signs include obfuscated multi-stage scripts, detached child processes, repeated background execution, hidden downloads from remote endpoints, and code that searches local browser profiles or wallet extension folders. Another red flag is silent collection of .log and .ldb files, especially when the package claims to be a simple utility and has no legitimate reason to touch sensitive user data.

Q: How should teams respond when a package registry compromise is suspected?

A: Contain the affected scopes, revoke publishing credentials, rotate adjacent secrets from any exposed runners or developer machines, and search for host persistence before reintroducing the package. If the compromise includes republishing behaviour, assume the incident extends beyond a single repository and coordinate across all affected namespaces.

Technical breakdown

How a postinstall hook turns package installation into execution

A postinstall hook is npm lifecycle code that runs automatically after a package is installed and before most human review can happen. In this case, the malicious release added a postinstall script that launched the worm payload immediately on install. That matters because package trust shifts from source code review to install-time execution, which means any dependency can behave like a runtime delivery vehicle. For defenders, the technical problem is not just malicious code in a repo, but an execution path triggered by ordinary developer workflows.

Practical implication: Treat install-time scripts as an execution control point and restrict packages that introduce new lifecycle hooks.

Why token theft becomes self-propagation in npm ecosystems

The worm component searches for npm credentials in .npmrc files, environment variables, and npm configuration, then enumerates every namespace the stolen token can publish to. It bumps patch versions, injects the payload, and republishes automatically. That creates a propagation loop: one compromised token can seed many packages, and every new install can produce new credentials for the next round. This is a classic credential-abuse pattern, but the non-human identity angle is central because the stolen asset is a publishing token with delegated authority over package namespaces.

Practical implication: Inventory publishing tokens by namespace and scope, then revoke any credential that can republish packages without explicit approval.

Persistence and takedown resistance come from the delivery path, not just the payload

The malware writes a Python backdoor to disk, registers a systemd user service, and polls a blockchain-hosted command-and-control endpoint. That combination makes it persistent without root, hard to remove from ordinary developer endpoints, and difficult to disrupt through domain takedowns. The technical lesson is that package compromise can create both an initial execution channel and a durable foothold, which broadens the incident from supply-chain poisoning to endpoint persistence. Once that happens, the attacker retains access even when destructive payloads never fire.

Practical implication: Look for persistence artefacts on developer hosts, not only malicious packages in registries.

Threat narrative

Attacker objective: The attacker seeks to turn one compromised publishing path into repeated package poisoning, durable access, and wider ecosystem compromise.

1. Entry occurs when a compromised npm package installs a postinstall hook that executes automatically during normal dependency installation.
2. Credential harvest follows as the payload collects npm tokens from .npmrc files, environment variables, and npm configuration on the victim system.
3. Escalation happens when the stolen tokens are used to republish backdoored patch releases across every namespace the attacker can reach.
4. Impact is ecosystem spread, persistent backdoors on developer hosts, and in some environments destructive payload delivery through the command-and-control channel.

Breaches seen in the wild

• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.
• 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).

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 publishing tokens are now production-grade credentials. The article shows that npm tokens can be transformed from build-time convenience into ecosystem-wide compromise paths when they are stolen from CI/CD environments. That moves them squarely into NHI governance territory because they authorize machine-to-machine actions with wide blast radius. Practitioners should govern publishing tokens as privileged non-human identities, not as disposable development secrets.

CanisterWorm demonstrates secret sprawl plus release trust is one control problem. The worm only worked because stolen credentials and trusted package distribution were chained together. A secret management program that stops at vaulting but does not constrain publishing authority still leaves a viable propagation path. The named concept here is publish-chain amplification, where one leaked token turns into repeated package republishing across namespaces. Practitioners should design controls around issuance, scope, and revocation together.

Persistence in package attacks now includes endpoint footholds, not just registry poison. The postinstall hook, systemd user service, and blockchain-hosted C2 show that supply-chain compromise can end in long-lived host access. That widens the governance boundary from software integrity to operational containment across developer machines and runners. NHI and platform teams should assume package compromise can become endpoint persistence unless execution and egress are both constrained.

CI/CD runners have become the bridge between identity governance and supply-chain security. The article links token theft to runner exposure, then to package republishing and downstream spread. That means IAM, PAM, and software supply-chain teams have to share the same control model for ephemeral credentials, workflow permissions, and publishing rights. Practitioners should align release pipeline governance with credential lifecycle management rather than treat them as separate programmes.

Destructive payloads change the stakes of npm compromise. The article shows that some victims could face filesystem wipe logic or Kubernetes-specific destructive actions, not just stealthy theft. That makes detection important, but containment and recovery planning are equally central because the same worm can function as both persistence and sabotage. Practitioners should treat malicious dependency execution as a resilience issue, not only a threat-intel event.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 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: CI/CD Pipeline Identity Security Guide

What this signals

Publish-chain amplification: package ecosystems now need controls that join credential lifecycle, release governance, and host persistence detection. A stolen publishing token is not just a secret leak, it is a potential replication mechanism that can turn one compromise into many, so teams should govern publishing rights as part of the non-human identity estate.

The CI/CD runner is the critical bridge in this pattern because it holds both the secret and the execution context. When a workflow can read tokens, publish packages, and contact the internet freely, the attacker does not need a separate intrusion path. The practical response is to narrow runner permissions, constrain egress, and treat install-time code as executable risk.

For practitioners

• Harden npm publishing tokens as privileged credentials Restrict who can mint, store, and use npm publishing tokens, and require explicit approval for any token that can publish to production namespaces. Treat tokens in CI/CD runners as high-impact secrets with least privilege and short exposure windows.
• Block new lifecycle scripts in dependency updates Flag any dependency update that introduces a first-time postinstall, preinstall, or similar lifecycle hook, because that is an execution path that runs before human review. Require extra scrutiny for packages that start executing code during install.
• Rotate every secret present in compromised pipelines If a workflow or runner was exposed, rotate npm tokens first and then any adjacent credentials that were available in the same environment, including cloud keys, GitHub tokens, and registry credentials. Assume the attacker harvested more than one secret class.
• Search hosts for persistence artefacts after suspicious installs Check developer endpoints and build machines for ~/.local/share/pgmon/service.py, ~/.config/systemd/user/pgmon.service, and unusual files such as /tmp/pglog or /tmp/.pg_state. Those artefacts indicate the payload executed and may still be active.
• Constrain egress from build and developer environments Allow only declared outbound destinations from CI/CD jobs and package-installation workflows so second-stage downloads and command-and-control polling cannot reach external infrastructure unchecked.

Key takeaways

• CanisterWorm shows that npm token theft is not a narrow package problem, because stolen publishing rights can be converted into propagation across many namespaces.
• The compromise path combines secret exposure, install-time execution, persistence, and republishing, which makes the blast radius far larger than a single infected release.
• The most relevant control boundary is the one between CI/CD credential access and package publication authority, because that is where the worm gets both entry and spread.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Legacy publishing token: A long-lived authentication credential used to publish or manage packages in a repository. In NHI governance, the risk is not only theft but persistence, because an unrevised token can remain valid after newer controls are added and can bypass the intended identity path.
• Command-and-Control Endpoint: The remote server an attacker uses to issue commands, stage payloads, or receive output from a compromised host. In dependency attacks, a stable endpoint can outlast package renames and serve as the most durable indicator of operator reuse.
• Republishing Worm: A republishing worm is malware that steals publishing rights and uses them to create additional malicious releases automatically. Its purpose is propagation, not just foothold persistence, so one compromised token can create a growing chain of infected packages.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to govern machine credentials, lifecycle controls, and delegated access with more discipline.