CanisterWorm: How April 2026’s Self-Propagating npm Attacks Steal Developer Tokens

A New Worm Class Built on Token Reuse

The April 2026 npm supply chain incidents represent a structural escalation from previous supply chain attacks. Earlier campaigns — including the November 2025 Shai-Hulud worm and the January 2026 pgserve incident — demonstrated that self-propagating npm worms were technically feasible. CanisterWorm demonstrates that this attack pattern has been refined, scaled, and deployed against a new target category: the agentic AI developer ecosystem.

The first poisoned release in the CanisterWorm campaign surfaced on April 8, 2026, when a tainted version of the pgserve package hit the registry. By April 21, the attack had expanded to Namastex Labs’ suite of agentic AI packages — @automagik/genie, @fairwords/websocket, and at least 20 additional packages — totaling 22 or more compromised packages in a single coordinated campaign.

What distinguishes CanisterWorm from a conventional malicious package is the self-propagation mechanism. The malicious postinstall script does not merely exfiltrate credentials to a command-and-control server and stop. It harvests the victim developer’s npm authentication token, uses that token to publish malicious updates to every package in the victim’s account, and launches itself as a fully detached background process — meaning the worm continues to run and propagate even after the developer’s npm install session completes. Each new victim developer who installs a compromised package from a legitimate, reputable maintainer becomes the next propagation node.

The attack infrastructure uses Internet Computer Protocol (ICP) canisters — decentralized smart contracts on the ICP blockchain — for both payload delivery and credential exfiltration. This infrastructure choice is deliberate: ICP canisters are difficult to take down quickly because there is no central server to seize or domain to null-route. Cloud Security Alliance’s CanisterSprawl research note confirmed strong technical overlap with the TeamPCP threat actor’s prior campaigns, including shared ICP infrastructure patterns and an explicit in-code reference to a “TeamPCP/LiteLLM method.”

What the Worm Actually Steals

The malicious postinstall script conducts a systematic credential harvest from the developer’s local environment. Specifically, it searches environment variables for token-related names and targets the following local files and directories:

npm credential files: .npmrc (containing npm auth tokens), scoped registry tokens, organization tokens for private package registries. With a valid npm token, the attacker can publish to any package the developer maintains — including private organizational packages and popular open-source libraries with millions of weekly downloads.

Git and cloud credentials: .git-credentials, .netrc, SSH private keys, and cloud service credential files for AWS, GCP, and Azure. The campaign simultaneously positions the attacker to access the victim’s code repositories, CI/CD pipelines, and cloud infrastructure.

Browser profiles and crypto wallets: Chrome and Firefox profile data, including browser-stored credentials and extensions for cryptocurrency wallets — MetaMask, Exodus, Atomic Wallet, and Phantom. This component reflects the TeamPCP actor’s documented interest in cryptocurrency theft alongside supply chain attacks.

Environment files: .env files, database password files, and any file matching token/key/secret patterns. Modern development environments routinely store API keys, database credentials, and service account tokens in .env files that a developer may not realize are accessible to postinstall scripts.

The scope of what a single compromised npm install can expose to a postinstall script is larger than most developers recognize. When npm install runs a postinstall script, that script executes with the same permissions as the developer’s shell — which in most development setups means access to the developer’s home directory, local credential stores, and mounted filesystems.

Why Agentic AI Packages Were Targeted

The targeting of Namastex Labs’ packages was not random. Namastex Labs develops agentic AI tooling — packages that connect AI agents to external services, APIs, and execution environments. Developers building on these packages are, by definition, working on systems where AI agents have broad permissions: shell access, API keys, database credentials, and service account tokens. Compromising the development environment of an agentic AI developer potentially exposes not just the developer’s credentials but the production credentials of every AI system they build and deploy.

This represents a targeting logic shift from previous supply chain attacks, which prioritized high-download-count packages for maximum breadth. CanisterWorm targets a lower-volume but higher-value category: developers whose compromised tokens unlock production AI systems with broad enterprise permissions. A single agentic AI developer’s npm token, combined with their .env files and AWS credentials, may provide access to AI agents managing customer databases, internal knowledge bases, or automated business processes.

The concurrent targeting of Bitwarden CLI users in a separate April 2026 campaign reinforces this logic. Bitwarden CLI is used by developers and system administrators to access password vaults programmatically — its users’ tokens unlock not just one service but the master credential store for entire development environments and infrastructure deployments.

What Enterprise Security Teams and Individual Developers Must Do

1. Rotate npm Authentication Tokens Immediately and Replace with OIDC

Any developer who has installed npm packages from the affected package list — particularly from the @automagik/, @fairwords/, or Namastex Labs namespaces since April 8, 2026 — should treat their npm authentication tokens as compromised and rotate them immediately. Token rotation in npm requires generating a new automation token via npm account settings and revoking the old one.

The structural fix is replacing long-lived npm classic tokens with short-lived, package-scoped OIDC (OpenID Connect) tokens. OIDC tokens are ephemeral — they expire after minutes or hours rather than persisting indefinitely — and are scoped to specific package namespaces rather than granting publish rights across an entire account. GitHub Actions, GitLab CI, and Bitbucket Pipelines all support OIDC token generation as a native feature for npm publish workflows. Organizations that have not yet migrated their publish pipelines to OIDC should treat this as a P1 security remediation, not a best-practice backlog item.

2. Enable ignore-scripts in CI/CD Environments as Default Policy

The ignore-scripts=true configuration in .npmrc prevents npm from executing preinstall, install, and postinstall scripts during npm install. For production CI/CD environments — where package installation should be deterministic and no arbitrary scripts should run — this setting eliminates the execution vector used by CanisterWorm, pgserve, and Shai-Hulud.

The tradeoff is that some packages use postinstall scripts for legitimate purposes (native module compilation, asset generation). In practice, most CI/CD pipelines can run with ignore-scripts=true by replacing postinstall-dependent packages with alternatives or by explicitly auditing and allowlisting the specific packages that require postinstall execution. This allowlisting approach is more secure than the current default (allow all postinstall scripts from all packages) and should become the enterprise standard for any CI environment that handles sensitive credentials.

3. Audit .env Files and Credential Stores for Over-Permissioned Access

The CanisterWorm postinstall script accesses developer home directories, .env files, browser profiles, and SSH key directories. These locations contain credentials that most developers consider ambient background infrastructure — present but not actively managed as security assets. A post-incident audit should inventory every credential stored in these locations and assess whether it is still needed, whether it is scoped to minimum necessary permissions, and whether it should be stored in a local credential file at all.

Specifically: AWS IAM credentials stored in ~/.aws/credentials should use temporary session tokens via AWS IAM Identity Center rather than long-lived access keys. API keys for production services should be stored in a secrets manager (HashiCorp Vault, AWS Secrets Manager) rather than .env files. SSH keys used for repository access should be FIDO2 hardware-backed where possible, eliminating the risk of file-based key theft. This credential hygiene review is the preventive control that limits blast radius for the next postinstall script attack — and there will be a next one.

4. Implement Dependency Version Pinning and Hash Verification in All Pipelines

CanisterWorm works by publishing a new, malicious version of a compromised package. A pipeline that specifies "@automagik/genie": "latest" in package.json would automatically pull the poisoned version on the next npm install. A pipeline that pins "@automagik/genie": "1.2.3" and verifies the package hash against a known-good value would not.

Lockfile management (package-lock.json for npm, yarn.lock for Yarn) enforces version pinning, but only if the lockfile is committed and the CI pipeline runs npm ci (which respects the lockfile) rather than npm install (which can update the lockfile). Hash verification goes further: tools like npm audit signatures verify that package signatures match the npm registry’s Sigstore-backed signature log, detecting packages where the published content has been tampered with after the maintainer’s signature. Sigstore-based supply chain provenance verification should be a standard CI gate for any organization installing packages from public registries.

The Structural Lesson: Self-Propagation Changes the Attack Economics

The critical innovation in CanisterWorm — and the reason this attack class will continue — is that self-propagation makes the attack exponentially scalable at near-zero marginal cost. A traditional supply chain attacker must compromise a specific, high-reputation package maintainer’s account through social engineering, credential theft, or key compromise — a high-effort, low-success-rate approach that limits campaign scale. A self-propagating worm compromises any developer who installs any affected package, then uses that developer’s own credentials to expand automatically to their entire maintained package portfolio.

The April 2026 incidents — CanisterWorm targeting agentic AI packages, the concurrent Bitwarden CLI incident — suggest the TeamPCP actor (and whoever they share infrastructure with) is iterating toward a sustainable attack model: target specific developer ecosystems with high credential value, self-propagate using the victim’s own trusted identity, and operate through decentralized C2 infrastructure that resists takedown. Security teams that implement the four controls above — OIDC token migration, ignore-scripts policy, credential scope reduction, and lockfile hash verification — are not just defending against CanisterWorm. They are closing the structural vulnerabilities that make all self-propagating supply chain worms possible.

Frequently Asked Questions

Sources & Further Reading

• Self-Propagating Supply Chain Worm Hijacks npm Packages to Steal Developer Tokens — The Hacker News
• Another npm Supply Chain Attack — The Register
• Namastex npm Packages Compromised in CanisterWorm Supply Chain Attack — SC World
• CanisterSprawl: The Self-Propagating npm Supply Chain Worm — Cloud Security Alliance Labs
• npm Supply Chain Security Best Practices — GitHub Blog
• GitLab Discovers Widespread npm Supply Chain Attack — GitLab Blog