CanisterWorm : ver npm auto-propagé via pgserve

Ce qui s'est passé

Une équipe de chercheurs en sécurité logicielle a identifié le 22 avril 2026 un ver ciblant le registre npm, qualifié de supply chain worm par The Hacker News et BleepingComputer. Baptisé CanisterWorm par les premiers analystes, le malware se distingue par sa capacité à s'auto-propager : une fois installé sur un poste développeur, il recherche dans les variables d'environnement et dans le fichier ~/.npmrc les tokens de publication npm encore valides, identifie les paquets que la victime est autorisée à publier, y injecte sa charge utile et republie les paquets avec un numéro de version incrémenté. Chaque installation ultérieure d'un paquet infecté rejoue le même processus, ce qui produit une propagation récursive et multi-écosystème.

Le premier vecteur documenté est le paquet pgserve publié par Namastex Labs, une société spécialisée dans les agents IA. Trois versions malveillantes successives ont été publiées le 21 avril à partir de 22h14 UTC. Lorsque les credentials PyPI sont également présents sur le poste de la victime, le ver étend son action à l'écosystème Python via une charge utile de type .pth, qui s'exécute automatiquement à chaque import de Python. L'attaque est ainsi polyglotte : un même poste développeur peut propager la contamination simultanément sur npm et PyPI.

Selon GitGuardian, trois campagnes de supply chain distinctes ont visé npm, PyPI et Docker Hub entre le 21 et le 23 avril 2026. Toutes cherchent à exfiltrer les mêmes classes de secrets : clés API des fournisseurs cloud, clés SSH, tokens de publication, credentials CI/CD. Les deux autres campagnes n'exploitent pas le mécanisme de ver mais diffusent des paquets miroir usurpant des dépendances légitimes pour piéger les installations automatiques.

Pourquoi c'est important

CanisterWorm franchit une étape par rapport aux attaques npm classiques : la propagation n'est plus limitée aux paquets initialement compromis, elle s'étend automatiquement à tous les paquets que les victimes peuvent publier. Un seul développeur infecté qui dispose de droits de publication sur plusieurs bibliothèques populaires peut, sans action délibérée, propager l'infection à des millions de dépendances téléchargées quotidiennement. Le mécanisme se rapproche des vers self-replicating connus dans le monde systèmes, transposés à la chaîne d'approvisionnement logicielle.

Pour les équipes de développement et de sécurité, la séquence d'attaques d'avril 2026 impose une révision des pratiques de gestion des tokens npm. Les tokens persistants stockés dans ~/.npmrc doivent être remplacés par des tokens éphémères, scoped au strict minimum, et idéalement émis par des runners CI au lieu d'être disponibles sur les postes développeur. Cette vague prolonge la série d'incidents ouverte par la compromission d'Axios npm et par les alertes récentes sur les outils d'admin détournés en backdoors. Combinée à la compromission massive de n8n et à la takeover complet de nginx-ui, la situation illustre une saison d'attaques concentrée sur l'infrastructure de livraison logicielle.

Ce qu'il faut retenir

• Auditer immédiatement le contenu de ~/.npmrc sur tous les postes développeur et les runners CI. Remplacer les tokens persistants par des tokens scoped et à durée de vie courte, et activer la vérification MFA sur les publications npm.
• Mettre en place un inventaire des paquets npm et PyPI utilisés dans les environnements de production, avec un pinning strict des versions et une vérification des sommes de contrôle. Les lock files doivent être revus avant tout merge.
• Surveiller les avis publiés par GitGuardian, Sonatype et Socket : ces acteurs ont pris l'habitude de publier rapidement les IOC et les noms des paquets compromis lors des campagnes récentes.