CanisterWorm shows how npm token theft becomes ecosystem spread

At a glance

What this is: This is an analysis of CanisterWorm, a self-propagating npm worm that used stolen publishing tokens to spread backdoored releases across multiple package namespaces.

Why it matters: It matters because CI/CD secret exposure can become ecosystem-wide package compromise, forcing IAM, PAM, and NHI teams to treat publishing tokens as high-risk operational identities.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.

👉 Read StepSecurity's analysis of CanisterWorm and npm token theft

Context

CanisterWorm is a supply-chain malware case that shows how a single exposed publishing token can become a propagation mechanism across an open-source ecosystem. The primary identity issue is not code execution alone, but credential governance failure: once npm tokens were stolen from compromised CI/CD workflows, they were reused as the trust boundary for publishing malicious packages.

For IAM and NHI teams, the lesson is that package registries, CI runners, and developer workstations all behave like identity-bearing systems when they can mint, store, or use secrets. That makes the boundary between human access, workload identity, and non-human publishing credentials operationally important rather than theoretical.

The starting position in this case is not atypical. High-trust build systems and long-lived tokens remain common in software supply chains, which means the attack path is repeatable wherever secret exposure is still treated as a detection problem instead of a lifecycle problem.

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 long-lived registry tokens increase supply chain compromise risk?

A: Long-lived registry tokens increase risk because they remain usable after the original workflow, host, or developer session that created them has changed. That gives attackers more time to reuse a stolen credential for publishing, republishing, or privilege escalation. Short-lived, context-bound credentials reduce the attack window and make offboarding meaningful.

Q: How do security teams know if malicious npm releases have already spread?

A: Teams should compare package release histories, maintainer changes, and install-time scripts across all internal and external dependencies. Signs of spread include unexpected patch versions, new postinstall behaviour, and publications from unfamiliar workflows or IP ranges. Once those markers appear, assume the release may already have reached developer and CI environments.

Q: Who is accountable when a compromised publish token is used to tamper with packages?

A: Accountability sits with the organisation that allowed a privileged credential to persist beyond the task it served. For IAM and PAM teams, that means the governance question is who owned the token lifecycle, who approved exceptions, and who accepted the blast radius created by standing access.

Technical breakdown

How npm postinstall hooks turn package installs into execution events

npm packages can run code during installation through lifecycle hooks such as postinstall. That means a package install is not just dependency retrieval, it is an execution path that fires before application logic or human review can intervene. In this case, the malicious release used postinstall to run index.js immediately, which then unpacked the payload and started persistence logic. The technical risk is not limited to one poisoned package version. Any downstream environment that automatically installs or rebuilds the package inherits the execution surface, including developer laptops and CI jobs.

Practical implication: constrain install-time execution and treat postinstall scripts as a gated risk signal in dependency intake.

How token harvesting from CI/CD pipelines enables namespace-wide abuse

The worm did not need to break npm itself. It first harvested publishing tokens from CI/CD environments, .npmrc files, environment variables, and npm config output, then used those credentials to publish malicious patch versions to every namespace the token could reach. That is a classic non-human identity abuse pattern: a legitimate publishing credential becomes the attacker’s delegated identity. Once the token is valid, registry trust and package ownership controls can be bypassed without further authentication challenges.

Practical implication: scope registry tokens narrowly, bind them to workflow context, and remove any standing publish credential from build environments.

Why persistence and blockchain-hosted C2 make cleanup harder

CanisterWorm combined local persistence with a command-and-control channel hosted on the Internet Computer blockchain. The malware wrote a systemd user service for restart persistence, then polled a decentralized endpoint that is harder to take down than conventional hosting. That design increases dwell time because defenders have to remove both the host-side implant and the credential source that allowed republishing. The destructive payload was secondary to the persistence model. The strategic objective is ongoing access, not one-time disruption.

Practical implication: incident response must include token revocation, host artifact removal, and registry audit, not just endpoint cleanup.

Threat narrative

Attacker objective: The attacker aimed to turn stolen publishing identity into repeatable package compromise, persistent access, and selective destructive capability across the npm ecosystem.

1. Entry occurred when developers or CI/CD jobs installed a compromised npm package that triggered a malicious postinstall hook.
2. Credential access followed as the payload harvested npm tokens from .npmrc files, environment variables, and npm config on the victim system.
3. Escalation and propagation happened when stolen publishing credentials were used to republish backdoored patch versions across every reachable namespace.
4. Impact included persistent host backdoors, wider package ecosystem spread, and destructive options for selected targets.

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

CanisterWorm is a publishing-identity attack, not just malware distribution. The worm works because npm tokens were treated as routine build artefacts rather than governed non-human identities. Once a publishing credential is stolen, package ownership becomes an abuse surface, and the attacker can impersonate the maintainer at ecosystem scale. Practitioner conclusion: registry tokens need the same lifecycle controls as privileged access.

Secret exposure and dependency trust are now the same control problem. The attack chain moved from CI/CD secret theft to backdoored package publication without ever needing a separate intrusion path. That collapses the traditional assumption that code review alone can stop malicious releases. Practitioner conclusion: dependency intake, secret handling, and build isolation must be governed together, not as separate teams or tools.

Persistent package malware raises the bar for NHI governance in software supply chains. The worm did not stop at credential theft. It also established user-level persistence and a resilient C2 channel, which means the stolen token becomes part of a broader operational foothold. Practitioner conclusion: lifecycle offboarding for publishing credentials must include immediate revocation, scope review, and blast-radius mapping.

Secret sprawl is now a propagation enabler, not just a hygiene issue. When secrets exist in .npmrc files, environment variables, and CI runners, the attacker has multiple harvesting points before a package is ever published. That is why hardcoded credentials and long-lived tokens remain a structural risk in modern software delivery. Practitioner conclusion: treat every secret location as a potential propagation source and remove standing publish access where possible.

From our research:

• From our research: 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• Our research also shows that internal repositories are 6x more likely to contain secrets than public ones, which reinforces why hidden developer and pipeline locations matter.
• Forward-looking guidance: Guide to the Secret Sprawl Challenge explains how secret sprawl becomes a lifecycle and blast-radius problem.

What this signals

Secret governance now needs to cover the full publication path, not just the code path. Teams that only watch repositories will miss the identities that matter most here, including CI runners, package publishing tokens, and developer-side .npmrc files. The operational signal is clear: treat package publishing as an identity event and tie it to revocation workflows, Guide to the Secret Sprawl Challenge, and registry audit trails.

Package ecosystems are becoming persistence environments. Once a stolen token is used to publish a malicious release, the attacker can keep operating through legitimate trust channels even after the original workflow is cleaned up. That means security programmes need better publisher offboarding, short-lived credentials, and dependency monitoring that reaches beyond the repo boundary, aligned to the OWASP Non-Human Identity Top 10.

CanisterWorm sharpens a new control concept: publishing-identity blast radius. The question is not only whether a secret was exposed, but how many namespaces, workflows, and downstream consumers that secret could reach before revocation. That is the metric IAM and PAM teams should start using when they assess software supply-chain identity risk.

For practitioners

• Revoke and rotate all publishing tokens tied to compromised workflows Identify every npm publishing token that existed on any runner, developer device, or workflow that handled the affected packages, then revoke those credentials and issue fresh scoped tokens only after integrity checks are complete.
• Block install-time execution on untrusted dependency updates Flag any newly introduced postinstall script as a security event, and require manual approval or sandboxing before dependency updates can reach production build paths.
• Audit package namespaces for unauthorized republishing Compare release histories across all maintainer-controlled scopes to find unexpected patch bumps, new maintainers, or package versions published from unrecognised IPs or workflows.
• Harden CI/CD secret handling for registry access Remove long-lived registry secrets from environment variables and shared runners, then move to short-lived, workflow-bound credentials with explicit publish approvals and repository-level separation.
• Search for persistence artifacts on developer and build hosts Check for ~/.local/share/pgmon/service.py, ~/.config/systemd/user/pgmon.service, and unusual outbound connections to the canister endpoint, because those artefacts indicate the payload executed locally.

Key takeaways

• CanisterWorm shows that stolen publishing tokens can be converted into ecosystem-wide package compromise, persistence, and selective destructive payloads.
• The breach path combined CI/CD secret theft, maintainer impersonation, and automatic package execution, which makes lifecycle control more important than detection alone.
• Teams should treat registry credentials as governed non-human identities, with tight scoping, rapid revocation, and install-time execution controls.

Key terms

• Package Install Hook: A package install hook is code that runs automatically when software is installed or imported. In npm, hooks such as preinstall can execute before a reviewer notices anything unusual, making them a common place to hide malicious behaviour inside otherwise trusted dependencies.
• 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.
• Self-propagating worm: A self-propagating worm is malware that automatically spreads from one compromised system to another without waiting for a human operator to copy it. In software supply chains, propagation often happens through trusted accounts, package registries, or update channels that the worm can reuse.
• Supply Chain Persistence: Supply chain persistence is the ability of an attacker to remain active by abusing trusted software distribution paths rather than staying on one host. It often relies on repeated publication, compromised maintainer access, or reusable automation secrets that let the attacker keep reintroducing malicious artifacts.

What's in the full article

StepSecurity's full analysis covers the operational detail this post intentionally leaves for the source:

• Full malicious package fingerprints, including affected npm scopes and version history patterns that help teams verify exposure
• Step-by-step host artifact checks for the Python implant, systemd service, and second-stage drop locations
• The full prevention, detection, and response workflow for npm supply-chain incidents across CI/CD and developer machines
• Package-level examples of how StepSecurity's controls would block cooldown bypass, exfiltration, and malicious republishes

👉 StepSecurity's full post covers the infection chain, host indicators, and package-level response steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and IAM fundamentals. It is designed for practitioners who need to connect identity lifecycle control to real-world supply chain risk.