npm Self-Propagating Worms in 2026: CanisterWorm, Bitwarden CLI & How TeamPCP Turns Developers into Malware VectorsVers Auto-Propagants npm en 2026 : CanisterWorm, Bitwarden CLI & Comment TeamPCP Transforme les Développeurs en Vecteurs de Malware

On April 22, 2026, the npm ecosystem had one of its worst days of the year — and it was not because of a single zero-day. Two separate but related incidents unfolded within hours of each other: a self-propagating worm was found in Namastex Labs npm packages under the campaign name CanisterWorm, and the widely-used @bitwarden/cli package was backdoored for 93 minutes via a compromised GitHub Actions pipeline. Both attacks are attributed to the same threat actor: TeamPCP.

These are not isolated incidents. They are the latest chapters in an 18-month escalation of self-propagating npm worms — malware that steals your npm publish token and uses it to infect every package you can publish. This guide covers the full technical breakdown, the campaign history, and the concrete defenses every Node.js team must implement today. Every statistic is verified from primary sources.

What Is a Self-Propagating npm Worm?

A self-propagating npm worm is a category of supply chain malware with a specific behavior that makes it categorically more dangerous than a standard backdoored package:

1. Install-time execution: The malicious payload runs automatically on npm install via a preinstall or postinstall hook — requiring zero user interaction.
2. Credential theft: It scans the developer's environment for npm authentication tokens, typically stored in ~/.npmrc, environment variables, or CI/CD secrets.
3. Package enumeration: Using the stolen token, it calls the npm registry API to list every package that token can publish.
4. Self-injection: For each package, it downloads the tarball, bumps the patch version, injects its own malicious postinstall hook, and republishes it to npm.
5. Cross-ecosystem propagation: If PyPI credentials are found, the worm generates a Python .pth-based payload and uploads malicious Python packages using twine.

The Shai-Hulud Lineage: 18 Months of Escalation

To understand CanisterWorm, you need to understand where it came from. This family of self-propagating npm malware has a documented history that Socket, Sysdig, Unit 42, and SecurityWeek have traced since September 2024:

September 2024 — Shai-Hulud v1 (First Wave)

ReversingLabs researchers detected the first-of-its-kind self-replicating worm on the npm registry on September 15, 2024. Named "Shai-Hulud" after the sandworms of Dune, it spread via cascading compromise of npm accounts, inserting malicious worm code into legitimate public and private npm packages belonging to compromised developers. More than 180 packages were infected in this first wave. (Source: SecurityWeek, Sysdig)

November 2024 — Shai-Hulud 2.0 (Second Wave)

A second, more sophisticated wave followed in November 2024. Shai-Hulud 2.0 successfully backdoored 796 unique npm packages, with 640 infected in a single wave. The worm added encrypted C2 communication via a dead-drop mechanism. Datadog Security Labs published a full technical breakdown of the new variant. (Source: SecurityWeek, Datadog Security Labs)

February 2026 — SANDWORM_MODE Campaign

The threat actor relaunched with a new campaign named SANDWORM_MODE, targeting AI developer tools. 19 packages explicitly named Claude Code, Cursor, and Windsurf as targets — a deliberate attempt to compromise developer machines through their AI coding assistants. (Source: Socket.dev, SecurityWeek)

March 20–23, 2026 — CanisterWorm (First Wave)

The campaign rebranded as CanisterWorm, named for its use of Internet Computer Protocol (ICP) canister infrastructure as a dead-drop for delivering follow-on binaries — making the C2 channel resistant to domain seizure. Between March 20–23, 141 packages were infected in 3 days, across at least 64 unique packages and 140+ package artifacts. (Source: Socket.dev, SC World)

April 8–22, 2026 — CanisterSprawl / Namastex Wave

The latest wave, now tracked by Socket as "CanisterSprawl," hit Namastex Labs — an agentic AI company. Two packages (@automagik/genie and @pgserve) were compromised, with 22 total packages affected since April 8. The ICP canister used was different from earlier CanisterWorm attacks, but Socket assessed it as likely part of the same campaign based on code lineage and tradecraft. (Source: Socket.dev)

April 22, 2026: Bitwarden CLI Backdoored for 93 Minutes

The same day as the Namastex disclosure, Bitwarden's security team identified and contained a malicious version of @bitwarden/cli. Version 2026.4.0 was published to npm at 5:57 PM ET and pulled at 7:30 PM ET — a window of exactly 93 minutes.

How Attackers Bypassed Bitwarden's Trusted Publishing

This was not a compromised developer account. Attackers infected the CI/CD pipeline itself. They modified publish-ci.yml in the github.com/bitwarden/clients repository, injecting malicious code into the GitHub Actions workflow that handles npm publishing. Because the attack originated inside Bitwarden's own trusted CI/CD infrastructure, standard npm token controls offered no protection. (Source: Endor Labs, Unit 42 Palo Alto Networks)

The Payload: Shai-Hulud, Third Coming

The malware explicitly identified itself in its code as "Shai-Hulud: The Third Coming" — a deliberate callback to the earlier Shai-Hulud campaigns, attributed to TeamPCP by multiple research teams. The payload was sophisticated and multi-stage:

• A malicious preinstall hook in bw_setup.js activated automatically on npm install
• It checked for the Bun runtime, downloading and installing it silently if absent
• A multi-cloud credential harvester targeted six distinct secret surfaces: GitHub tokens, npm publish tokens, AWS credentials, GCP service accounts, SSH private keys, and MCP/AI agent configuration files
• Data was exfiltrated to the domain audit.checkmarx[.]cx (a lookalike of the legitimate Checkmarx brand) with a GitHub commit as encrypted fallback
• A self-propagation module found all packages publishable by the stolen npm token, bumped the patch version, injected the worm payload, and republished them
• Shell RC persistence was established (~/.bashrc, ~/.zshrc) to survive package removal

TeamPCP: The Threat Actor Behind the Campaigns

All three waves — CanisterWorm, Bitwarden CLI, and the earlier Shai-Hulud attacks — have been attributed to TeamPCP, a financially motivated hacking group active since at least 2024. The group is also tracked under the aliases DeadCatx3, PCPcat, and ShellForce. (Source: JFrog Security Research, OX Security)

TeamPCP's prior high-profile targets include:

• March 2026: Trivy (security scanner) — 82 tags force-pushed on GitHub Actions, 10,000+ CI/CD pipelines exposed
• March 2026: LiteLLM on PyPI — 95M downloads/month, credential theft within 40 minutes of infection
• March 2026: Checkmarx CLI on PyPI — compromised via the same GitHub Actions pipeline vector

The group demonstrates a consistent modus operandi: target high-trust packages used by developers and security tools, compromise via CI/CD rather than direct account takeover, and use self-propagation to maximize ecosystem spread without requiring additional infrastructure per victim. The use of AI agent tooling as a target vector (MCP configs, Cursor, Claude Code) suggests a deliberate strategy to harvest credentials from developer machines with broad cloud access.

Scale: Key Statistics

How the Self-Propagation Works — Technical Deep-Dive

The self-propagation logic documented in CanisterWorm and the Bitwarden CLI payload follows a consistent pattern across all variants. Here is the step-by-step mechanism, based on Socket.dev's and Endor Labs' technical analyses:

# Simplified pseudocode of the self-propagation logic
# (as documented by Socket.dev and Endor Labs — not original malware code)

1. Read ~/.npmrc or process.env.NPM_TOKEN → steal publish token
2. Call npm registry: GET /-/whoami → get authenticated username
3. Call npm registry: GET /-/v1/search?text=maintainer:[username] → list publishable packages
4. For each package:
   a. Download current tarball: npm pack [package-name]
   b. Extract tarball, inject malicious postinstall hook into package.json
   c. Bump patch version (1.2.3 → 1.2.4)
   d. Re-pack tarball, publish: npm publish --tag latest
5. If ~/.pypirc or TWINE_PASSWORD found:
   → Generate Python .pth payload, upload via twine to PyPI

The result: a single compromised developer machine can infect every npm package they maintain within minutes, expanding the attack surface by orders of magnitude without requiring the attacker to compromise additional accounts. This is why Socket.dev describes it as "turning one compromised developer environment into additional package compromises."

The ICP Canister Dead-Drop

What distinguishes CanisterWorm from earlier Shai-Hulud variants is its command-and-control infrastructure. Instead of a traditional HTTP server or domain, the malware uses an Internet Computer Protocol (ICP) canister as a dead-drop to deliver follow-on binaries. Because ICP canisters are hosted on a decentralized blockchain network, they cannot be taken down via traditional domain seizure or law enforcement requests — making the infrastructure highly resilient. (Source: Socket.dev, SC World)

Concrete Defenses for Node.js Teams

1. Audit your npm token scope — immediately

The self-propagating mechanism depends entirely on having a publish token. Granular publish access tokens (available in npm settings) restrict a token to specific packages. A token that can only publish my-widget cannot be used to spread malware to your other 30 packages. For CI/CD, use npm's OIDC-based provenance attestation instead of long-lived tokens — this prevents token theft from being exploitable for publishing. (Source: npm Documentation)

# Create a granular access token scoped to a specific package
npm token create --scope=@your-org/specific-package --type=publish

# List and audit all active tokens
npm token list

# Revoke a compromised token immediately
npm token revoke [token-id]

2. Enable npm package provenance

npm provenance links a published package to its specific source commit and CI/CD run, creating a cryptographically verifiable chain. When enabled, the npm registry shows a "Provenance" badge on the package page and any publish attempt outside the attested workflow fails. The Bitwarden CLI attack succeeded despite Bitwarden using GitHub Actions — if mandatory provenance had been enforced on the consumer side, organizations could have detected the unsigned publish before installation.

# In your GitHub Actions publishing workflow:
- name: Publish to npm with provenance
  run: npm publish --provenance --access public
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

3. Monitor postinstall hook execution in CI

The entire self-propagating mechanism relies on postinstall hooks. You can disable them for installs in CI environments where you trust your lockfile:

# Install without running lifecycle scripts (postinstall, preinstall)
npm ci --ignore-scripts

# For production Docker builds
npm ci --omit=dev --ignore-scripts

Caveat: Some packages require postinstall scripts for native bindings compilation. Audit your package.json to identify which packages use install hooks before disabling globally.

4. Use Socket.dev or similar dependency security tooling

Socket.dev detected the CanisterWorm Namastex packages within hours of publication by analyzing package behavior at install time, not just comparing against a known-CVE database. Traditional npm audit only catches CVEs that have been formally assigned and indexed — it would not catch a freshly published malicious package. Socket's behavioral analysis flagged the suspicious postinstall hook before the campaign was publicly attributed.

5. Treat CI/CD credentials with the same rigor as production secrets

The Bitwarden CLI attack did not compromise a developer's personal machine — it compromised the GitHub Actions workflow. This means secrets stored in GitHub Actions environment variables (NPM_TOKEN, AWS_ACCESS_KEY_ID, cloud credentials) were accessible to the injected payload. Recommendations:

• Use OIDC-based short-lived credentials for cloud providers (AWS, GCP) from GitHub Actions — tokens expire after each workflow run
• Enable required reviewers for environment deployments so the publish step cannot run without human approval
• Audit GitHub Actions workflow files for unexpected changes — especially publish*.yml files — as part of your standard code review process
• Monitor outbound connections from CI runners — CanisterWorm's exfiltration to audit.checkmarx[.]cx would have been caught by network egress monitoring

6. Rotate credentials immediately after any suspicious install

If you installed any package later found to be part of the CanisterWorm or Bitwarden CLI campaigns, the remediation steps are:

1. Revoke all npm publish tokens and reissue with minimal scope
2. Rotate GitHub personal access tokens and GitHub Actions secrets
3. Rotate AWS/GCP credentials present in environment variables
4. Rotate SSH keys (check ~/.ssh/ for any new authorized keys)
5. Check shell configuration files (~/.bashrc, ~/.zshrc) for persistence mechanisms
6. Audit all packages you can publish for unexpected version bumps in the past 7 days

Frequently Asked Questions

Le 22 avril 2026, l'écosystème npm a vécu l'une de ses pires journées de l'année — non pas à cause d'un unique zero-day, mais de deux incidents liés qui se sont déroulés à quelques heures d'intervalle. Un ver auto-propagant a été découvert dans les packages npm de Namastex Labs sous le nom de campagne CanisterWorm, et le package @bitwarden/cli a été backdooré pendant 93 minutes via un pipeline GitHub Actions compromis. Les deux attaques sont attribuées au même acteur malveillant : TeamPCP.

Ces incidents ne sont pas isolés. Ils représentent les derniers chapitres d'une escalade de 18 mois de vers npm auto-propagants — des malwares qui voléent votre token de publication npm et l'utilisent pour infecter chaque package que vous pouvez publier. Ce guide couvre l'analyse technique complète, l'historique de la campagne, et les défenses concrètes que toute équipe Node.js doit implémenter. Chaque statistique est vérifiée depuis des sources primaires.

Qu'est-ce qu'un ver npm auto-propagant ?

Un ver npm auto-propagant est une catégorie de malware supply chain avec un comportement spécifique qui le rend fondamentalement plus dangereux qu'un package backdooré classique :

1. Exécution à l'installation : La payload malveillante s'exécute automatiquement lors de npm install via un hook preinstall ou postinstall — sans aucune interaction utilisateur.
2. Vol de credentials : Il scanne l'environnement du développeur à la recherche de tokens npm, typiquement dans ~/.npmrc, les variables d'environnement ou les secrets CI/CD.
3. Enumération des packages : Avec le token volé, il interroge l'API du registre npm pour lister tous les packages que ce token peut publier.
4. Auto-injection : Pour chaque package, il télécharge le tarball, incrémente la version patch, injecte son propre hook postinstall malveillant et republie sur npm.
5. Propagation cross-écosystème : Si des credentials PyPI sont trouvés, le ver génère une payload Python via .pth et uploade des packages malveillants sur PyPI.

La lignée Shai-Hulud : 18 mois d'escalade

Pour comprendre CanisterWorm, il faut retracer son historique. Cette famille de malwares npm auto-propagants a une histoire documentée que Socket, Sysdig, Unit 42 et SecurityWeek ont retracie depuis septembre 2024 :

Septembre 2024 — Shai-Hulud v1 (première vague)

Les chercheurs de ReversingLabs ont détecté le premier ver auto-réplicant sur le registre npm le 15 septembre 2024. Nommé "Shai-Hulud" d'après les vers des sables de Dune, il s'est propagé via compromission en cascade de comptes npm, infectant des packages publics et privés. Plus de 180 packages ont été infectés dans cette première vague. (Source : SecurityWeek, Sysdig)

Novembre 2024 — Shai-Hulud 2.0 (deuxième vague)

Une deuxième vague plus sophistiquée a suivi en novembre 2024. Shai-Hulud 2.0 a backdooré 796 packages npm uniques, avec 640 infectés en une seule vague. Le ver ajoutait une communication C2 chiffrée via un mécanisme dead-drop. (Source : SecurityWeek, Datadog Security Labs)

Février 2026 — Campagne SANDWORM_MODE

L'acteur malveillant a relancé avec une nouvelle campagne nommée SANDWORM_MODE, ciblant les outils de développement IA. 19 packages ciblaient explicitement Claude Code, Cursor et Windsurf. (Source : Socket.dev)

20-23 mars 2026 — CanisterWorm (première vague)

La campagne s'est rebaptisée CanisterWorm, d'après son utilisation de l'infrastructure ICP (Internet Computer Protocol) comme dead-drop, résistante aux saisies de domaines. Entre le 20 et le 23 mars, 141 packages ont été infectés en 3 jours. (Source : Socket.dev)

8-22 avril 2026 — CanisterSprawl / Vague Namastex

La dernière vague, trackée par Socket comme "CanisterSprawl", a frappé Namastex Labs. Les packages @automagik/genie et @pgserve ont été compromis, avec 22 packages total affectés depuis le 8 avril. (Source : Socket.dev)

22 avril 2026 : Bitwarden CLI backdooré pendant 93 minutes

Le même jour que la divulgation Namastex, l'équipe de sécurité de Bitwarden a identifié et contenu une version malveillante de @bitwarden/cli. La version 2026.4.0 a été publiée sur npm à 17h57 ET et retirée à 19h30 ET — une fenêtre de exactement 93 minutes.

Comment les attaquants ont contourné la publication de confiance

Ce n'était pas un compte développeur compromis. Les attaquants ont infecté le pipeline CI/CD lui-même. Ils ont modifié publish-ci.yml dans le dépôt github.com/bitwarden/clients, injectant du code malveillant dans le workflow GitHub Actions gérant la publication npm. (Source : Endor Labs, Unit 42)

La payload : Shai-Hulud, Troisième Avènement

Le malware s'identifiait explicitement dans son code comme "Shai-Hulud: The Third Coming". La payload était sophistiquée et multi-étape :

• Un hook preinstall malveillant dans bw_setup.js s'activait automatiquement à l'installation
• Un harvester multi-cloud ciblait six surfaces de secrets distinctes : tokens GitHub, tokens npm, credentials AWS, comptes de service GCP, clés SSH, et fichiers de configuration MCP/agents IA
• Les données étaient exfiltrées vers le domaine audit.checkmarx[.]cx (lookalike de Checkmarx) avec un commit GitHub comme fallback chiffré
• Un module d'auto-propagation trouvait tous les packages publiables avec le token volé, incrémentait la version patch, injectait le ver et republiait
• Une persistance shell RC était établie dans ~/.bashrc et ~/.zshrc

Mesures de protection immédiates

1. Auditez vos tokens npm — maintenant

Le mécanisme d'auto-propagation dépend entièrement d'un token de publication. Les tokens d'accès granulaires npm restreignent un token à des packages spécifiques. Un token limité à mon-widget ne peut pas être utilisé pour propager un malware à vos 30 autres packages. Pour le CI/CD, utilisez la publication de confiance OIDC de npm — les tokens expirent après chaque run de workflow.

# Lister et auditer tous les tokens actifs
npm token list

# Révoquer un token compromis immédiatement
npm token revoke [token-id]

# Créer un token granulaire limité à un package
npm token create --scope=@votre-org/mon-package --type=publish

2. Désactiver les scripts postinstall en CI

Tout le mécanisme d'auto-propagation repose sur l'exécution des hooks postinstall. En environnement CI où vous faites confiance à votre lockfile, désactivez-les :

# Installer sans exécuter les scripts lifecycle
npm ci --ignore-scripts

3. Activer la provenance npm

La provenance npm lie un package publié à son commit source spécifique, créant une chaîne vérifiable cryptographiquement. Toute tentative de publication en dehors du workflow attested échoue automatiquement.

4. Révoquer les credentials si vous avez installé un package compromis

Si vous avez installé @bitwarden/cli@2026.4.0 ou l'un des packages Namastex affectés, traitez l'événement comme une exposition de credentials confirmée et révoquez immédiatement : tokens npm, tokens GitHub, credentials AWS/GCP, clés SSH, et clés API présentes dans les variables d'environnement.

Questions fréquentes