Analyse post-mortem de l’attaque de la chaîne d’approvisionnement Tinycolor

(sigh.dev)

3 points par GN⁺ 2025-09-20 | Aucun commentaire pour le moment. | Partager sur WhatsApp

De nombreux paquets npm incluant le paquet open source @ctrl/tinycolor ont été infectés par des versions malveillantes ; la cause était le vol d’un token npm via un workflow GitHub Actions dans un dépôt collaboratif
L’attaquant a utilisé un token npm aux permissions étendues pour publier du code malveillant dans environ 20 paquets ; parmi eux, @ctrl/tinycolor avait un impact important avec 2 millions de téléchargements hebdomadaires
Les versions infectées exécutaient une charge utile malveillante à l’étape postinstall, et les équipes de sécurité de GitHub et npm ont réagi rapidement pour supprimer et nettoyer les versions concernées
L’auteur a préparé un plan de sécurité renforcé pour éviter une récidive, avec migration vers Trusted Publishing (OIDC), réduction minimale des permissions des tokens, obligation de la 2FA et utilisation de fonctionnalités de pnpm
Cet incident montre la fragilité de la sécurité de la chaîne d’approvisionnement logicielle et met en évidence la nécessité d’améliorer les fonctions de sécurité et les pratiques de sécurité dans tout l’écosystème npm

TL;DR

Un workflow GitHub Actions malveillant a été poussé dans un dépôt partagé afin de voler un token npm
Avec ce token, l’attaquant a publié des versions malveillantes de 20 paquets, dont @ctrl/tinycolor, très diffusé, ce qui a amplifié l’impact
Les comptes personnels et les dépôts n’ont pas été compromis directement, et il n’y a pas eu de phishing ni d’installation locale de malware
Grâce à la réaction rapide des équipes de sécurité de GitHub et npm, les versions malveillantes ont été supprimées, puis des versions propres ont été republiées pour purger les caches

Le 15 septembre dans l’après-midi, le membre de la communauté Wes Todd a signalé le problème via un DM sur Bluesky
Les équipes de sécurité de GitHub et npm avaient déjà commencé à établir la liste des paquets affectés et à lancer leur suppression
Un premier indice partagé était le nom de branche malveillante « Shai-Hulud », tiré du ver des sables de l’univers de Dune

Un collaborateur d’un ancien dépôt commun, angulartics2, disposait encore des droits admin
Le token npm stocké dans ce dépôt a été volé par un workflow GitHub Actions malveillant
L’attaquant a utilisé ce token pour publier environ 20 paquets, dont @ctrl/tinycolor
Les équipes de sécurité de GitHub et npm ont rapidement supprimé les versions malveillantes, puis l’auteur a republié de nouvelles versions de confiance

L’installation des versions malveillantes déclenchait un script postinstall, créant un risque de sécurité
Il est recommandé aux utilisateurs concernés de consulter les consignes de réponse immédiate de StepSecurity

Jusqu’ici, la publication automatique reposait sur la combinaison semantic-release + GitHub Actions
La fonctionnalité npm provenance était utilisée, mais elle ne pouvait pas empêcher un attaquant disposant d’un token valide
À l’avenir, l’objectif est d’adopter Trusted Publishing (OIDC) pour supprimer les tokens statiques
Pour l’instant, tous les tokens ont été révoqués et des mesures de sécurité supplémentaires sont en cours d’application : 2FA obligatoire, autorisation uniquement de tokens à permissions granulaires, examen de la fonctionnalité minimumReleaseAge de pnpm

Il faudrait proposer au niveau du compte npm une option imposant Trusted Publishing basé sur OIDC
Il faudrait pouvoir bloquer la publication en l’absence de provenance et assurer une intégration complète entre semantic-release et OIDC
L’auteur souhaite une fonctionnalité de publication avec approbation manuelle basée sur la 2FA dans l’interface GitHub
Il devrait être possible d’utiliser des protections au niveau de GitHub Environments même sans abonnement Pro
Les pages des paquets npm devraient indiquer la présence d’un script postinstall et rendre public le motif de suppression des versions retirées