Attaque supply chain npm : le ver CanisterWorm infecte Trivy via 47 paquets

Une attaque de chaîne d’approvisionnement logicielle a contaminé 47 paquets npm avec un ver auto-réplicant, surnommé CanisterWorm dans plusieurs échanges de réponse à incident. Le scénario est celui que tu redoutes dans une équipe dev, un composant « de confiance » se transforme en point d’entrée, puis la compromission s’étend sans attendre une seconde vague manuelle.

Le plus marquant, ce n’est pas seulement le vol de secrets. Le code malveillant a été conçu pour se propager d’un mainteneur à d’autres projets, en visant les environnements de développement et de CI/CD où traînent des tokens, des clés cloud et des identifiants. Des analystes ont rapidement relié cette campagne à une escalade plus large, avec des chiffres qui montent au-delà de 40 paquets au départ, puis bien plus selon les investigations.

Sonatype décrit une propagation de type ver via scripts npm

Les analyses techniques décrivent un malware qui combine deux fonctions, l’exfiltration de secrets et la réplication dans l’écosystème. Concrètement, il s’appuie sur des mécanismes courants de npm, notamment des scripts exécutés lors de l’installation, pour déposer du code et préparer l’étape suivante. Là où une attaque classique s’arrête à « voler puis partir », le ver cherche à multiplier les points d’appui.

Des paquets précis ont été cités dans les listes d’artefacts compromis, par exemple @ctrl/ts-base32 (versions 4.0.1 et 4.0.2) ou plusieurs modules de l’écosystème @nativescript-community. Dans une équipe produit, ce genre de dépendances peut se retrouver indirectement dans une app mobile, un outil interne, ou un service Node, sans que personne ne l’ait « choisi » explicitement. C’est ce caractère transitive qui rend le nettoyage long.

Un ingénieur sécurité, « Marc », résume le piège de façon très simple, « tu peux avoir des tests, des revues, une CI propre, si ton pipeline installe une version contaminée, tu viens d’exécuter l’attaquant chez toi ». Nuance importante, toutes les organisations ne sont pas touchées de la même manière, celles qui pinent strictement les versions et bloquent les scripts d’installation réduisent l’exposition, mais beaucoup d’équipes gardent des réglages permissifs pour aller vite.

Arctic Wolf relie l’attaque à @ctrl/tinycolor et à TruffleHog

Selon les bulletins de réponse à incident, l’alerte publique a pris de l’ampleur autour de la compromission de @ctrl/tinycolor, avec un point de départ identifié sur une première brique malveillante, rxnt-authentication, mise à jour le 14 septembre 2025 à 17:58:50 UTC. Le schéma, c’est une mise à jour « normale » en apparence, puis une diffusion qui s’accélère au fur et à mesure que des comptes et des environnements sont exposés.

Le volet collecte de secrets est décrit de façon très opérationnelle, le malware scanne les machines et projets à la recherche d’identifiants, de clés cloud et de tokens, en s’appuyant sur des outils de détection de secrets comme TruffleHog. Ce détail compte, parce qu’il montre un attaquant qui sait exactement où chercher dans la vie réelle, dépôts git, variables d’environnement, caches de CI, fichiers de configuration oubliés.

La chaîne d’exfiltration mentionnée est tout sauf exotique, des données volées peuvent transiter via des dépôts publics GitHub, ce qui complique la détection si tu ne surveilles pas activement tes propres fuites. Marc, encore lui, note un angle mort courant, « beaucoup d’équipes surveillent la prod, moins le poste dev et les runners CI, alors que c’est là que les clés vivent ». Critique au passage, l’écosystème dépend trop d’habitudes implicites, publier vite, mettre à jour vite, installer vite, sans garde-fous uniformes.

Palo Alto Networks et GitLab détaillent phishing, paquets populaires et « dead man’s switch »

Le risque n’est pas théorique, des paquets très téléchargés ont été touchés dans la vague décrite début septembre 2025, avec chalk, debug ou ansi-styles cités parmi les dépendances compromises. À eux seuls, 18 paquets ciblés représentaient environ 2,6 milliards de téléchargements hebdomadaires, ce qui donne l’échelle, une modification minuscule peut se retrouver partout, y compris dans des produits qui n’ont jamais « voulu » de dépendance risquée.

Le point d’entrée décrit dans cette séquence passe par du phishing, un mainteneur a été trompé par de faux messages de support réclamant une mise à jour de sécurité, puis l’accès au compte a permis de publier des versions modifiées. C’est là que la nuance s’impose, on parle d’un écosystème bâti sur la confiance, mais la confiance repose sur des humains, et les humains se font piéger, même avec de l’expérience.

GitLab a signalé des comportements de propagation « worm-like » et, plus inquiétant, la présence d’un mécanisme de dead man’s switch menaçant de détruire des données si certains canaux d’exfiltration ou de propagation sont coupés. Dans les extraits analysés, on voit aussi l’ajout de scripts preinstall et l’usage d’outils d’exécution pour automatiser publication et infection. GitLab indique avoir vérifié ne pas utiliser les paquets malveillants, mais l’épisode rappelle une réalité simple, la sécurité open source dépend autant des pratiques de publication que des contrôles côté entreprises.