TanStack compromis : 84 versions npm piégées par Mini Shai-Hulud

Les faits

Le 11 mai 2026 en début de soirée, l''écosystème npm a essuyé sa plus grosse attaque chaîne d''approvisionnement depuis la première vague Shai-Hulud de septembre 2025. En six minutes, entre 19h20 et 19h26 UTC, un attaquant identifié sous le nom de TeamPCP a publié 84 versions malveillantes réparties sur 42 paquets de la collection @tanstack/*. Le coup a été détecté publiquement vingt minutes plus tard par le chercheur Ashish Kurmi de StepSecurity, ce qui a déclenché l''alerte coordonnée chez TanStack, npm Security et plusieurs équipes de réponse à incident.

La cible n''est pas anodine : @tanstack/react-router à lui seul totalise plus de 12 millions de téléchargements hebdomadaires sur npm, et la suite TanStack (Query, Table, Form, Router) est consommée directement ou en transitif par une part significative de l''écosystème React et Solid moderne. Les chiffres consolidés par Aikido Security et Socket.dev portent l''ampleur réelle de la campagne, baptisée Mini Shai-Hulud, à 169 paquets compromis au total, touchant aussi UiPath, Squawk et Mistral, soit bien au-delà du seul périmètre TanStack.

Le mode opératoire combine trois faiblesses connues mais rarement chaînées dans une même opération. Premièrement, un workflow GitHub Actions configuré avec le déclencheur pull_request_target, motif que la documentation GitHub qualifie depuis 2021 de Pwn Request lorsqu''il manipule du code de la fork. Deuxièmement, un empoisonnement du cache GitHub Actions qui franchit la frontière de confiance entre le dépôt fork et le dépôt base. Troisièmement, et c''est la nouveauté technique de cette campagne, l''extraction en mémoire vive du jeton OIDC depuis le processus du runner GitHub Actions, ce qui permet d''obtenir un jeton de publication npm valide sans avoir besoin de voler un secret de dépôt.

Une fois le jeton OIDC capté, l''attaquant publie sous l''identité légitime du mainteneur. C''est ce qui rend la détection initiale par les outils classiques de signature inopérante : techniquement, les versions sont signées par le bon compte, validées par npm, et apparaissent dans le registre comme des releases ordinaires. Le contenu malveillant prend la forme d''un script postinstall qui s''exécute à l''installation du paquet et exfiltre le contenu des fichiers .env, des fichiers de credentials AWS et GCP, ainsi que des variables d''environnement présentes dans le processus parent. Les données sont envoyées vers une infrastructure de réception jetable que les analystes ont reliée à TeamPCP via les signatures réseau.

Le caractère auto-réplicatif est l''autre pivot de cette campagne. Mini Shai-Hulud, comme la première version Shai-Hulud, contient une routine de propagation : lorsqu''il s''exécute dans un environnement CI où des jetons npm sont disponibles dans des variables d''environnement, il tente de publier de nouvelles versions malveillantes des paquets sur lesquels les jetons disposent d''un accès en écriture. Cette mécanique virale est ce qui a porté la campagne de 84 versions chez TanStack à 169 paquets sur l''écosystème npm en moins de deux heures, avec un effet boule de neige sur les organisations qui partagent des chaînes CI/CD entre projets internes et publications open source.

TanStack a publié le 12 mai un postmortem détaillé reconnaissant la responsabilité de configuration côté workflow et listant l''ensemble des paquets affectés. Toutes les versions identifiées comme malveillantes ont été dépréciées sur npm, et l''équipe de sécurité npm a engagé une procédure de retrait des tarballs pour empêcher leur résolution même par référence directe. Les responsables d''Aikido Security insistent toutefois sur le fait que les caches privés type Verdaccio, Artifactory ou les miroirs internes peuvent encore servir des versions malveillantes pendant des heures, voire des jours, le temps que les politiques de purge se déclenchent.

L''affaire intervient une semaine seulement après la documentation par SentinelLabs du ver cloud PCPJack, signé par le même groupe TeamPCP. Cette concentration d''opérations laisse penser à une montée en compétence et en outillage du collectif, qui passe d''un ciblage opportuniste sur des conteneurs exposés à des chaînes d''approvisionnement logicielles à très haute portée. Les analystes de Socket.dev notent que la fenêtre d''attaque de six minutes témoigne d''une automatisation poussée de la phase de publication, vraisemblablement scriptée à partir d''un harnais Action GitHub préparé en amont.

Impact et exposition

Toute organisation ayant exécuté un npm install, npm ci ou pnpm install sur un projet consommant @tanstack/* entre le 11 mai 19h20 UTC et le 12 mai 02h00 UTC est potentiellement exposée. Le risque maximal pèse sur les pipelines CI/CD non isolés où des secrets de production transitent dans l''environnement Node : tokens AWS, clés GCP, jetons GitHub, secrets npm, variables Vercel, Netlify, Cloudflare. Les postes de développeurs sont également visés, en particulier ceux qui conservent des fichiers .env à la racine de plusieurs projets. Les builds en lockfile strict avec versions épinglées sont protégés si et seulement si le lockfile a été généré avant le 11 mai 19h20 UTC et n''a pas été régénéré depuis.

Recommandations

• Lister immédiatement les builds CI ayant tourné sur des paquets @tanstack/* depuis le 11 mai 19h20 UTC, ré-épingler les versions à un état antérieur à cette date.
• Faire tourner sans délai tous les secrets exposés à un runner ayant exécuté un de ces paquets : tokens npm, AWS, GCP, GitHub PAT, jetons OIDC.
• Auditer les caches privés (Verdaccio, Artifactory, Nexus, GitLab Package Registry) et purger toute version compromise listée dans le postmortem TanStack.
• Activer la double authentification sur les comptes mainteneurs npm critiques et passer aux jetons granulaires plutôt qu''aux jetons classiques.
• Migrer les workflows GitHub Actions sensibles loin de pull_request_target ou ajouter une étape de revue manuelle obligatoire avant exécution sur du code de fork.